Skip to content
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.

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

time: Location interprets wrong timezone (DST) with slim zoneinfo [1.15 backport] #42138

Closed
hlubek opened this issue Oct 22, 2020 · 36 comments
Closed

Comments

@hlubek
Copy link

@hlubek hlubek commented Oct 22, 2020

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

$ go version
go version go1.15.3 linux/amd64

Does this issue reproduce with the latest release?

Yes, but it seems to be fixed in master with d83168e.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build587886067=/tmp/go-build -gno-record-gcc-switches"

What did you do?

How to reproduce: https://gist.github.com/hlubek/f46a73bc9d150cf1f2af585b0849e3d9

  • Added a compiled Go binary to a very simple Alpine Docker image with installed tzdata package
  • Timezones (e.g. Europe/Berlin) uses wrong daylight saving information (e.g. CEST instead of CET for dates after October, 25th in 2020)
  • This seems to be caused by changes in the tzdata package in Alpine
  • It does not occur if the tzdata Alpine package is not installed and the embedded zoneinfo time/tzdata is used

What did you expect to see?

  • An error when loading the location with a non compatible zoneinfo

What did you see instead?

  • A wrongly interpreted date

Notes

This is already fixed with d83168e but I wonder why there is no info about that issue (took me some time to figure it out) or a test for the code added to zoneinfo_read.go. This is quite a standard setup for packaging Go programs so I could think many people are affected by this. The fix turns out to only work if the cached zone for now() is the same as the last transition. This broke after the last clock change on October, 25th for CET/CEST.

@MattBrittan
Copy link

@MattBrittan MattBrittan commented Oct 22, 2020

I believe this may be a broader issue. This commit to zic changed the default format from fat to slim and that change was pushed out with the 2020b release. This means that the issue is likely to occur wherever 2020b or later timezone files are used (unless the package maintainer overrides the defaults when running zic). With daylight saving ending in many countries this weekend this issue may have a significant impact.

Edit: For those looking for a workaround here are a few options until a fix is released:

  • Use the ZONEINFO environmental variable to select a different zone file (e.g. export ZONEINFO=/usr/local/go/lib/time/zoneinfo.zip github ).
  • Include the tzdata package in your app (and do not install tzdata in the container - the package is only used if the time package cannot find tzdata files on the system).
  • Use a container built from scratch (in combination with one of the above options)
  • Recompile the relevant tz files in 'fat' mode (instructions)
  • Pin an earlier alpine version (i.e. alpine:3.8) that uses 2020a or earlier (note that version 3.8 is past its End of Support date).
@tklauser
Copy link
Member

@tklauser tklauser commented Oct 22, 2020

@tklauser
Copy link
Member

@tklauser tklauser commented Oct 22, 2020

When working on https://golang.org/cl/261363 (commit 5b509d9) I noticed that some of the tests in package time failed due to the zic change mentioned in #42138 (comment), see e.g. https://storage.googleapis.com/go-build-log/29cd3aeb/linux-amd64_58c05150.log.

I investigated this further and figured out that there is an issue with the way we cache location data, which lead to https://golang.org/cl/261877 (commit d83168e). In addition, this should probably haven been reported as an issue to make it easier to discover, which I didn't do. Sorry about that.

I guess what we could do is backport the changes in src/time/zoneinfo_read.go from https://golang.org/cl/261877 to 1.15 but I'll defer to @ianlancetaylor to decide on that.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 22, 2020

Yes, I think this is likely due to the very recent change in the default tzdata install. We didn't notice until now because the change was so recent. Since fortunately @tklauser has already found and fixed the problem on tip, and since more and more people are going to be using slim tzdata installations, I agree that we should backport the fix.

This should be a straightforward backport for 1.15. Unfortunately it is more work for 1.14, which doesn't have the tzset function introduced in https://golang.org/cl/215539. So perhaps we will have to backport that also to 1.14.

I'll repurpose this issue for 1.15 and open a backport issue for 1.14.

@ianlancetaylor ianlancetaylor added this to the Go1.15.4 milestone Oct 22, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 22, 2020

@gopherbot Please open backport for 1.14.

Without a backport people using Go 1.14 with a new tzdata installation will not get the correct timezone information.

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 22, 2020

Backport issue(s) opened: #42155 (for 1.14).

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

@gopherbot gopherbot commented Oct 22, 2020

Change https://golang.org/cl/264301 mentions this issue: [release-branch.go1.15] time: support slim tzdata format

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 22, 2020

@hlubek It would be helpful if you could check that https://golang.org/cl/264301 fixes the problem for you. It is a patch against 1.15. Thanks.

@hlubek
Copy link
Author

@hlubek hlubek commented Oct 23, 2020

@hlubek It would be helpful if you could check that https://golang.org/cl/264301 fixes the problem for you. It is a patch against 1.15. Thanks.

Sure, will do!

@dsantos
Copy link

@dsantos dsantos commented Oct 26, 2020

@hlubek I've tried using https://golang.org/cl/264301 and it didn't work as expected, unless I am missing something

@hlubek
Copy link
Author

@hlubek hlubek commented Oct 26, 2020

@dsantos I could reproduce that the patch fixes the issue reproduced in https://gist.github.com/hlubek/f46a73bc9d150cf1f2af585b0849e3d9 (Alpine with tzdata package) by using a patched Go toolchain to compile a binary for the image.

Could you provider more details on your issue?

@dsantos
Copy link

@dsantos dsantos commented Oct 26, 2020

Picking up from your example, this is how I've tested it:

FROM golang:1.15 as builder

RUN git clone --branch release-branch.go1.15 https://go.googlesource.com/go /root/goroot &&\
	cd /root/goroot/src &&\
	git fetch https://go.googlesource.com/go refs/changes/01/264301/1 && git checkout FETCH_HEAD &&\
	./make.bash

WORKDIR /app

COPY . .

RUN CGO_ENABLED=0 /root/goroot/bin/go build -o bin/test

# ---

FROM alpine:3.12

RUN apk update &&\
    apk --no-cache add tzdata &&\
    rm -rf /var/cache/apk/*

COPY --from=builder /app/bin/test /app/test

CMD ["/app/test"]
@hlubek
Copy link
Author

@hlubek hlubek commented Oct 26, 2020

@dsantos Thanks, I can see it's failing and I digged a little deeper here.

I took the test from https://go-review.googlesource.com/c/go/+/264301 and applied it to the golang image together with the patch and it failed. Before it was working for me. I think it's possible that the extend handling is not correct depending on the now where the cache zone is built (because we had the clock change to DST since early Sunday). And if I update the now seconds to the day before (sec -= 200000) the test will succeed.

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 26, 2020

Change https://golang.org/cl/264939 mentions this issue: time: fix LoadLocationFromTZData with slim tzdata

@hlubek
Copy link
Author

@hlubek hlubek commented Oct 26, 2020

I implemented a fix for tip that could be applied to the backport: https://go-review.googlesource.com/c/go/+/264939

@hlubek hlubek changed the title time: Location interprets wrong timezone (DST) with slim zoneinfo time: Location interprets wrong timezone (DST) with slim zoneinfo [1.15] Oct 26, 2020
@e3matheus
Copy link

@e3matheus e3matheus commented Oct 27, 2020

For anyone facing this issue, I switched to time zone data en Go using this: https://medium.com/@mhcbinder/using-local-time-in-a-golang-docker-container-built-from-scratch-2900af02fbaf.

This caused a lot of problems in our site since last week, using America/Mexico_City. A new deploy with docker, would not calculate the correct tz data and we displayed different dates on our site.

@rob-lowcock
Copy link

@rob-lowcock rob-lowcock commented Oct 27, 2020

This caused us a few problems as we were using alpine:latest as our base image, which currently uses 2020c-r0 for tzdata. For anyone looking for a workaround, we pinned our version to alpine:3.8 and that seemed to do the trick (as it uses 2020a-r0).

@butuzov
Copy link

@butuzov butuzov commented Oct 27, 2020

bogosj added a commit to bogosj/go-tesla-go that referenced this issue Oct 28, 2020
Pin to alpine:3.8.5 until golang/go#42138 is resolved, hopefully in go 1.15.4.
@magiconair
Copy link
Contributor

@magiconair magiconair commented Oct 28, 2020

I am able to reproduce this with Alpine 3.12 but not Alpine 3.11. So you might not have to go back as far as 3.8. Can someone else confirm this?

@MattBrittan
Copy link

@MattBrittan MattBrittan commented Oct 28, 2020

@magiconair I based the versions in my comment on the Alpine packages page which indicates that tzdata 2020c is current for all versions >3.8. I have just tested this (under docker) and can replicate the problem on versions 3.9-3.12 but 3.8 is OK.

@glycerine
Copy link

@glycerine glycerine commented Oct 29, 2020

If need be, I suspect (for go1.15.x) one might be able to build with -tags timetzdata to work around this too. If you embed a non-slim tz file during build and then it can be deployed anywhere... maybe?

@dmitshur dmitshur changed the title time: Location interprets wrong timezone (DST) with slim zoneinfo [1.15] time: Location interprets wrong timezone (DST) with slim zoneinfo [1.15 backport] Oct 29, 2020
@dmitshur
Copy link
Member

@dmitshur dmitshur commented Oct 29, 2020

Approving per discussion in a release meeting. This is a serious issue without a workaround. This backport applies to both 1.15 (this issue) and 1.14 (#42155).

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 29, 2020

Closed by merging 414668c to release-branch.go1.15.

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 29, 2020

Change https://golang.org/cl/266299 mentions this issue: [release-branch.go1.15] time: fix LoadLocationFromTZData with slim tzdata

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2020

gopherbot why are you closing this issue?

gopherbot pushed a commit that referenced this issue Oct 29, 2020
Backport of part of https://golang.org/cl/261877 to support the slim
tzdata format. As of tzdata 2020b, the default is to use the slim format.
We need to support that format so that Go installations continue to
work when tzdata is updated.

Relevant part of the CL description:

    The reason for the failed tests was that when caching location data, the
    extended time format past the end of zone transitions was not
    considered. The respective change was introduced in (*Location).lookup
    by CL 215539.

For #42138

Change-Id: I37f52a0917b2c6e3957e6b4612c8ef104c736e65
Reviewed-on: https://go-review.googlesource.com/c/go/+/264301
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2020

Filed #42277 about gopherbot.

@mangas
Copy link

@mangas mangas commented Oct 29, 2020

@dmitshur @ianlancetaylor any idea when we can expect a release with this fix on 1.15?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2020

We usually do minor releases at the start of each month, so, if all goes well, next week.

@mangas
Copy link

@mangas mangas commented Oct 29, 2020

This tz issue has a considerable impact and the workaround (finding a compatible tzdata version) is not great, don't suppose there is any chance to have it earlier?

@dmitshur dmitshur reopened this Oct 29, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2020

Earlier than next week? It's already Thursday, and we don't want to make a release on Friday, so I don't see how we can do earlier than next week.

There is an easy temporary workaround for Go 1.15: go build -tags=timetzdata. See https://golang.org/pkg/time/tzdata.

gopherbot pushed a commit that referenced this issue Oct 29, 2020
…data

The extend information of a time zone file with last transition < now
could result in a wrong cached zone because it used the zone of the
last transition.

This could lead to wrong zones in systems with slim zoneinfo.

For #42216
Fixes #42138

Change-Id: I7c57c35b5cfa58482ac7925b5d86618c52f5444d
Reviewed-on: https://go-review.googlesource.com/c/go/+/264939
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 70e022e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/266299
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 29, 2020

This should now be fixed on the 1.15 release branch.

@choonkeat
Copy link
Contributor

@choonkeat choonkeat commented Oct 30, 2020

For those looking for a workaround here are a few options until a fix is released:
Use the ZONEINFO environmental variable to select a different zone file (e.g. export ZONEINFO=/usr/local/go/lib/time/zoneinfo.zip github ).

curious: what's the downside of using /usr/local/go/lib/time/zoneinfo.zip all the time (not as a "workaround", regardless of whether 1.15 etc is patched) instead of depending on another packaging system (alpine tzdata) ?

UPDATE: relying on Go toolchain update schedule for time zone data updates isn't the best setup. e.g. there could be projects that for whatever reason need to be pegged at certain Go versions, and having that to mean the time zone info is also outdated isn't right 🙇‍♂️ Thanks Matt

@gonzaloserrano
Copy link

@gonzaloserrano gonzaloserrano commented Nov 5, 2020

Sorry to bother but I'm able to understand if there is any workaround while the new version is released (which is not using the release branch one I mean).

@tklauser
Copy link
Member

@tklauser tklauser commented Nov 5, 2020

Sorry to bother but I'm able to understand if there is any workaround while the new version is released (which is not using the release branch one I mean).

A temporary workaround is described in #42138 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.