如何修复损坏的 tzdata2020c 高山时区数据库？

Question

我刚刚偶然发现了 tzdata2020c 高山软件包的一个错误。在 2020 年 10 月 25 日下周日计划更改夏令时后，它不会计算欧洲/柏林的正确时间。版本 tzdata2020c 使用 CEST，例如 2020 年 10 月 31 日和欧洲/柏林时区，而 CET 是正确的。 有人知道如何手动添加新版本的 tzdata2020d 数据库，该数据库可在此处获得。我用 Go 编写的应用程序在 2020 年 10 月 31 日使用 tzdata2020c 错误地使用了欧洲/柏林的 CEST：同一应用程序在 2020 年 10 月 31 日使用 tzdata2020a 正确使用了欧洲/柏林的 CET：

Answer 1

手动安装tzdata2020d文件本身并不能解决此问题。但是以下应该（使用golang:alpinedocker 映像成功测试）：

mkdir tz

cd tz

wget https://www.iana.org/time-zones/repository/releases/tzdata2020d.tar.gz

tar -xvf tzdata2020d.tar.gz

zic -b fat -d zoneinfo/ europe

cp zoneinfo/Europe/Berlin /usr/share/zoneinfo/Europe/Berlin

其他解决方法包括：

• 升级到 Go 1.15.4或1.14.11。

• 使用ZONEINFO 环境变量选择不同的区域文件（例如export ZONEINFO=/usr/local/go/lib/time/zoneinfo.zip;zoneinfo.zip在go 安装中）。

• 在您的应用程序中包含tzdata包（并且不要在容器中安装 tzdata - 该包仅在时间包无法在系统上找到 tzdata 文件时使用）。

• 使用从头开始构建的容器（结合上述选项之一）

• 固定使用 2020a或更早版本的早期 alpine 版本（即 alpine:3.8）（请注意，版本 3.8 已超过其支持结束日期）。

原因

此问题是由应用程序更改引起的zic；在2020b版本中包含的版本之前，此默认设置为fat正确处理应用程序的模式。默认是 nowthin并且 go 不支持该格式（没有这个补丁）。不幸的是，该LoadLocation功能静默失败（返回不正确的区域信息）。

无论何时使用 2020b 或更高版本的时区文件，都可能出现此问题（除非包维护者在运行时覆盖了默认值zic）。

zic细节

iana将时区信息作为一系列文本文件与许多应用程序一起分发。这些应用程序之一是zic将文本文件处理为部署到的二进制文件 ( RFC 8536/usr/share/zoneinfo ) 。

此提交将默认输出格式从 更改fat为slim。这样做的结果是，使用 2020b 或更高版本生成的时区文件将无法被 Go 正确读取（除非它们是使用-b fat参数创建的）。

去修复

这在 Go 1.15.4和1.14.11中已修复。

已经提出了一个问题，该问题已通过最近的一次提交部分修复（该提交的主要目的是减小time/tzdata包的大小，但也应该解决这个问题）。请参阅此问题重新修复的其他部分。

测试

以下应用程序演示了该问题：

package main

import (

    "fmt"

    "time"

)

func main() {

    b, err := time.LoadLocation("Europe/Berlin")

    if err != nil {

        panic(err)

    }

    t := time.Date(2020, 10, 23, 11, 00, 00, 00, time.UTC)

    fmt.Printf("1: %s %s\n", t, t.In(b))

    t = time.Date(2020, 10, 31, 11, 00, 00, 00, time.UTC)

    fmt.Printf("2: %s %s\n", t, t.In(b))

}

截至 10 月 19 日，输出（Docker 下的 Alpine 3.12）为：

1: 2020-10-23 11:00:00 +0000 UTC 2020-10-23 13:00:00 +0200 CEST

2: 2020-10-31 11:00:00 +0000 UTC 2020-10-31 13:00:00 +0200 CEST

这是不正确的，因为第 31 个应该是CET（Alpine 3.8 生成正确的结果）。

Answer 2

在 alpine:3.9 图像上遇到了同样的问题，并根据英国人的回答设法修复了它。谢谢。