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

[hlubek]

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]

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]

/cc @ianlancetaylor

[tklauser]

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]

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]

@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]

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]

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

[ianlancetaylor]

@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]

@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!