time: time zone lookup using extend string makes wrong start time for non-DST zones #58682
Comments
|
Change https://go.dev/cl/471020 mentions this issue: |
thanm
added
the
NeedsInvestigation
|
@rsc per owners. |
|
@ianlancetaylor |
|
@gopherbot Please open backport issues We incorrectly handle the timezone bounds for timezones that used to have daylight savings time and then stopped. |
|
Backport issue(s) opened: #59074 (for 1.19), #59075 (for 1.20). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
|
Change https://go.dev/cl/478657 mentions this issue: |
|
Change https://go.dev/cl/478658 mentions this issue: |
…ones This change fixes time.LoadLocationFromTZData and time.Location.lookup logic if the given time is after the last transition and the extend string doesn't have the DST rule. For #58682 Fixes #59075 Change-Id: Ie34a6d658d14c2b33098b29ab83c041ef0d34266 GitHub-Last-Rev: f6681eb GitHub-Pull-Request: #58684 Reviewed-on: https://go-review.googlesource.com/c/go/+/471020 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> (cherry picked from commit 90dde5d) Reviewed-on: https://go-review.googlesource.com/c/go/+/478658 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com>
…ones This change fixes time.LoadLocationFromTZData and time.Location.lookup logic if the given time is after the last transition and the extend string doesn't have the DST rule. For #58682 Fixes #59074 Change-Id: Ie34a6d658d14c2b33098b29ab83c041ef0d34266 GitHub-Last-Rev: f6681eb GitHub-Pull-Request: #58684 Reviewed-on: https://go-review.googlesource.com/c/go/+/471020 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> (cherry picked from commit 90dde5d) Reviewed-on: https://go-review.googlesource.com/c/go/+/478657 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com>
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
What did you expect to see?
Since the last transition in
Asia/Seoulon Sunday, 9 October 1988, 02:00:00, the expected result:What did you see instead?
Debugging
It seems like
time.LoadLocationFromTZDataandtime.Location.lookupwork inappropriately if the time is after the last transition and theextendstring doesn't have DST rule.I think the problematic parts are these:
Based on tzfile(5) manual, the
extendstring is applied to the last transition, but the above codes pass the last transition's end time(omega), andtzsetuses it as a start time in non-DST case.It leads us to two problems:
time.Time.ZoneBoundsmethod returns wrong results.cacheStartisomega.Due to the second problem, some operations that need timezone information for non-DST fall into significant performance degradation.
This is a
benchstatresult after solving the problem for some cases. (inAsia/Seoul)The text was updated successfully, but these errors were encountered: