Skip to content

time: LoadLocationFromTZData with slim tzdata uses incorrect zone #44385

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
vcabbage opened this issue Feb 18, 2021 · 8 comments
Closed

time: LoadLocationFromTZData with slim tzdata uses incorrect zone #44385

vcabbage opened this issue Feb 18, 2021 · 8 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.

Comments

@vcabbage
Copy link
Member

What version of Go are you using (go version)?

$ go version
go version go1.16 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?

Loaded tzdata with both "fat" and "slim" formats.

What did you expect to see?

Same time zone info regardless of whether using "fat" or "slim" tzdata.

What did you see instead?

Incorrect zones selected when using "slim" tzdata.

Comparing "fat" and "slim" versions of the 2021a tzdata I found 9 discrepancies:

America/Godthab
        FAT:   -03 | -10800
        SLIM:  -02 |  -7200
America/Nuuk
        FAT:   -03 | -10800
        SLIM:  -02 |  -7200
America/St_Johns
        FAT:   NST | -12600
        SLIM:  NST | -12652
Asia/Gaza
        FAT:   EET |   7200
        SLIM: EEST |  10800
Asia/Hebron
        FAT:   EET |   7200
        SLIM: EEST |  10800
Asia/Jerusalem
        FAT:   IST |   7200
        SLIM:  IDT |  10800
Asia/Tel_Aviv
        FAT:   IST |   7200
        SLIM:  IDT |  10800
Canada/Newfoundland
        FAT:   NST | -12600
        SLIM:  NST | -12652
Israel
        FAT:   IST |   7200
        SLIM:  IDT |  10800

Script used (doesn't work in playground): https://play.golang.org/p/iaduStbpjnU

time/tzdata is affected in Go 1.16 since it now uses the "slim" format.

Related: #42216
@vcabbage
Copy link
Member Author

Some of the listed time zones are duplicates.
America/Godthab has been deprecated and replaced with America/Nuuk
Canada/Newfoundland has been deprecated and replaced withAmerica/St_Johns
Asia/Tel_Aviv and Israel have been deprecated and replaced withAsia/Jerusalem

@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 18, 2021
@ianlancetaylor
Copy link
Contributor

Thanks for finding these cases. Sending a fix.

@ianlancetaylor ianlancetaylor self-assigned this Feb 25, 2021
@seankhliao seankhliao added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 25, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/296392 mentions this issue: time: correct unusual extension string cases

@vcabbage
Copy link
Member Author

@ianlancetaylor Thanks! Should this be considered for a 1.16 patch release since it affects time/tzdata?

@ianlancetaylor
Copy link
Contributor

@gopherbot Please open backport issues.

We mishandle a couple of cases in the time extension strings used by the slim tzdata format. The slim format is likely to appear on more and more systems going forward, and is what we use when people use the time/tzdata package.

This was referenced Feb 25, 2021
Closed
Closed
@gopherbot
Copy link
Contributor

Backport issue(s) opened: #44617 (for 1.15), #44618 (for 1.16).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/297229 mentions this issue: [release-branch.go1.15] time: correct unusual extension string cases

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/297230 mentions this issue: [release-branch.go1.16] time: correct unusual extension string cases

gopherbot pushed a commit that referenced this issue Mar 1, 2021
@ianlancetaylor @dmitshur
[release-branch.go1.16] time: correct unusual extension string cases
88f91b7 
This fixes two uncommon cases.

First, the tzdata code permits timezone offsets up to 24 * 7, although
the POSIX TZ parsing does not. The tzdata code uses this to specify a
day of week in some cases.

Second, we incorrectly rejected a negative time offset for when a time
zone change comes into effect.

For #44385
Fixes #44618

Change-Id: I5f2efc1d385e9bfa974a0de3fa81e7a94b827602
Reviewed-on: https://go-review.googlesource.com/c/go/+/296392
Trust: Ian Lance Taylor <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Tobias Klauser <[email protected]>
(cherry picked from commit d9fd38e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297230
gopherbot pushed a commit that referenced this issue Mar 1, 2021
@ianlancetaylor @dmitshur
[release-branch.go1.15] time: correct unusual extension string cases
6bb9600 
This fixes two uncommon cases.

First, the tzdata code permits timezone offsets up to 24 * 7, although
the POSIX TZ parsing does not. The tzdata code uses this to specify a
day of week in some cases.

Second, we incorrectly rejected a negative time offset for when a time
zone change comes into effect.

For #44385
Fixes #44617

Change-Id: I5f2efc1d385e9bfa974a0de3fa81e7a94b827602
Reviewed-on: https://go-review.googlesource.com/c/go/+/296392
Trust: Ian Lance Taylor <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Tobias Klauser <[email protected]>
(cherry picked from commit d9fd38e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297229
@golang golang locked and limited conversation to collaborators Feb 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ianlancetaylor @gopherbot @vcabbage @seankhliao