I just stumbled upon a bug with the tzdata2020c package for alpine. It does not calculate the correct time for Europe/Berlin after the scheduled change of daylight savings time next Sunday October 25th, 2020. Version tzdata2020c uses CEST for e.g. the 31st of October 2020 and Europe/Berlin timezone whereas CET would be correct.
Does anybody know how to manually add a new version of the tzdata2020d database which is available here.
My application, written in Go, incorrectly uses CEST for Europe/Berlin at 31st October 2020 using tzdata2020c:
The same application correctly uses CET for Europe/Berlin at 31st October 2020 using tzdata2020a:
Manually installing the
tzdata2020d
files will not, in itself, fix this. However the following should (successfully tested with thegolang:alpine
docker image):Other workarounds include:
ZONEINFO
environmental variable to select a different zone file (e.g.export ZONEINFO=/usr/local/go/lib/time/zoneinfo.zip
;zoneinfo.zip
is in the go installation).Cause
This problem was caused by a change in the
zic
application; prior to the version included with 2020b release this defaulted tofat
mode which go applications correctly processed. The default is nowthin
and go does not support that format (without this patch). Unfortunately theLoadLocation
function fails silently (returning incorrect zone information).The issue is likely to occur wherever 2020b or later timezone files are used (unless the package maintainer overrides the defaults when running
zic
).zic
detailsiana distributes the timezone information as a series of text files along with a number of applications. One of these applications is
zic
which processes the text files into the binary files (RFC 8536) which are deployed to/usr/share/zoneinfo
.This commit changed the default output format from
fat
toslim
. The upshot of this is that timezone files produced using the 2020b, or later, files will not be read correctly by Go (unless they are created using the-b fat
argument).Go Fix
This is fixed in Go 1.15.4 and 1.14.11.
An issue has been raised and the issue is partly fixed by a recent commit (the main aim of that commit was to reduce the size of the
time/tzdata
package but should also fix this). See this issue re the other part of the fix.Testing
The following application demonstrates the issue:
The output (Alpine 3.12 under Docker), as at 19th October, is:
This is incorrect because the 31st should be
CET
(Alpine 3.8 generates the correct result).