问题标签 [tzdata]

我正在尝试在本地主机上的 phoenix 中启动我的应用程序，但我从 tzdata 收到一个错误，导致应用程序无法启动。我对凤凰没有任何经验，所以欢迎任何帮助。这是我尝试命令时遇到的错误mix phoenix.server

目前我通过链接/etc/localtime到我的 Linux CentOS 7 机器上设置时区 GMT+5/usr/share/zoneinfo/Etc/GMT-5.

例如，我想创建一个区域信息文件/usr/share/zoneinfo/Etc/GMT-5:30，使我能够将当前时区设置为 GMT+5:30 ，而不必担心 DST 更改。

我知道我可以链接/etc/localtime到/usr/share/zoneinfo/Asia/Kolkata例如，但我将不得不担心 DST 更改，即使它可能不会同时实施。

我也知道，TZ=GMT+5:30; export $TZ但我担心这种方法将来会因某种原因适得其反。

我在 Debian Stable 9 (stretch) 上，新更新的非洲/卡萨布兰卡 TZ 数据库表当前状态为 isdst=0，与 UTC 的偏移量为 +01。来自摩洛哥的夏令时 Wiki 页面

https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco

很明显，从 2018 年 10 月起添加了 UTC +1:00 的永久偏移量，现在永久遵守夏令时。

但在斋月期间，偏移量传统上被重置为 UTC 00:00。但是 TZ 数据库表示他们添加了 +01 的偏移量，并且 isdst 设置为 1。

此问题仅适用于非洲/卡萨布兰卡。

这似乎是 Debian Stable 的问题。感谢您提供有关解决此问题的任何建议

zdump -v /usr/share/zoneinfo/Africa/Cas​​ablanca | 2019 年

/usr/share/zoneinfo/Africa/Cas​​ablanca 2019 年 5 月 5 日星期日 01:59:59 UT = 2019 年 5 月 5 日星期日 02:59:59 +01 isdst=0 gmtoff=3600

/usr/share/zoneinfo/Africa/Cas​​ablanca 2019 年 5 月 5 日星期日 02:00:00 UT = 2019 年 5 月 5 日星期日 02:00:00 +00 isdst=1 gmtoff=0

/usr/share/zoneinfo/Africa/Cas​​ablanca 2019 年 6 月 9 日星期日 01:59:59 UT = 2019 年 6 月 9 日星期日 01:59:59 +00 isdst=1 gmtoff=0

/usr/share/zoneinfo/Africa/Cas​​ablanca 2019 年 6 月 9 日星期日 02:00:00 UT = 2019 年 6 月 9 日星期日 03:00:00 +01 isdst=0 gmtoff=3600

我在一堆已安装的 Elixir 服务器上收到错误消息，因为我们正在下载2019btzdata，但检查已发布版本的代码仍在报告已2019a发布。是什么触发了更新ets.lookup(:tzdata_current_release, :release_version)以及为什么会被破坏？我想这不是手动的，也不是我的责任。

loaded_tzdata_matches_remote_last_modified?/0:Tzdata.ReleaseUpdater.tzdata release in place is from a file last modified Tue, 26 Mar 2019 05:40:14 GMT. Release file on server was last modified Mon, 01 Jul 2019 16:50:25 GMT.

我也遇到了这个错误，它可能是独立的，如果是这样可以分离到另一个问题。只是检查想法。

[错误] error_info/7:gen_server.888 GenServer :tzdata_release_updater terminating#012** (FunctionClauseError) 在 Tzdata.Util.first_matching_weekday_in_month/4#012 (tzdata) lib/tzdata/util.ex:73 中没有函数子句匹配：Tzdata。 Util.first_matching_weekday_in_month(1932, 4, 7, [])#012
(tzdata) lib/tzdata/util.ex:329: Tzdata.Util.time_for_rule/2#012
(tzdata) lib/tzdata/period_builder.ex:161: Tzdata.PeriodBuilder.calc_periods_for_year/9#012 (tzdata) lib/tzdata/period_builder.ex:180: Tzdata.PeriodBuilder.calc_periods_for_year/9#012 (tzdata) lib/tzdata /period_builder.ex:185: Tzdata.PeriodBuilder.calc_periods_for_year/9#012 (tzdata) lib/tzdata/period_builder.ex:180: Tzdata.PeriodBuilder.calc_periods_for_year/9#012 (tzdata) lib/tzdata/period_builder.ex:185 : Tzdata.PeriodBuilder.calc_periods_for_year/9#012 (tzdata) lib/tzdata/period_builder.ex:180: Tzdata.PeriodBuilder.calc_periods_for_year/9#012最后一条消息: :check_if_time_to_update

我正在使用以下基本映像的容器中运行我的应用程序：

FROM mcr.microsoft.com/dotnet/core/aspnet:2.2-stretch-slim AS base

当我发布应用程序时，容器时区是Greenwich Mean Time，因此我在数据库中的 NLog 条目关闭了 6 小时。

我可以通过进入容器并运行来更改时区， dpkg-configure tzdata重新启动容器后，我的日志条目变得正常。但是，我想知道这是否可以通过 Dockerfile 或运行标志来完成？

1941 年 7 月 3 日 (00:00:00) 和 1941 年 7 月 4 日 (00:00:00) 的 mktime 返回是出乎意料的。两者相差82800秒，少了一小时（3600）。

C 程序 diff1941.c（见下文）显示以下内容：

起初我以为是 TZ 数据库小时班，但据我了解，根据 zdump 命令，1941 年没有这种班次。

所以在这一点上我很困惑。我的程序有一个我看不到的错误（可能），或者 lib C mktime 函数中有一个错误（不太可能），或者 TZ 数据库中有一些微妙的东西我找不到它（可能）：怎么办你觉得呢？

我在用：

• Ubuntu 20.04 64 位，
• libc 2.31-0ubuntu9,
• tzdata 2019c-3ubuntu1
• /usr/share/zoneinfo/Europe/Paris 上的 /etc/localtime 点

diff1941.c：

我有需要 Java6 的旧版软件。我正在尝试通过 tzupdater.jar 更新 java TZ 库。我已成功安装 tzdata2019c.tar.gz ，但无法安装 tzdata2020a

以下是详细信息：

我在互联网上没有找到答案。

伊奥拉纳！来自复活节岛的问候！

我在 Android 中使用 JodaTime 2.10.6 打印 EAST、PDT、GMT、EEST 等日期的时区缩写：

在任何 Android 设备上，都会打印：

......但我想要制作的是EAST或者EASST我无法得到它们中的任何一个！

如果我在本地单元测试上运行相同的代码（在计算机上执行，而不是在 Android 上执行），我会得到想要的结果：

我调试了原因，而 JodaTime 使用的DefaultNameProvider显然是从平台本身获取所有时区名称组：DateFormatSymbols.getZoneStrings()在 JDK 和 Android 中实现不同。

Android 似乎正在进入libcore.icu本机实现的领域，并且似乎缺少所提供的 600 个时区中大部分的缩写。然而，JDK 几乎拥有所有这些！没有一个实现是可调试的。

• Android TZ 名称（坏）：

• JDK TZ 名称（好）：

我一直认为 JodaTime 拥有所有时区信息并且独立于平台数据。我不知道他们依赖底层平台来提供这些时区名称？

有没有NameProvider可用的，我可以插入 JodaTime，也许是一些专门基于捆绑的 TZData 的实现？

或者我可以让它在Android上正确打印这些时区缩写的任何其他方式？

毛鲁-你！

我刚刚偶然发现了 tzdata2020c 高山软件包的一个错误。在 2020 年 10 月 25 日下周日计划更改夏令时后，它不会计算欧洲/柏林的正确时间。版本 tzdata2020c 使用 CEST，例如 2020 年 10 月 31 日和欧洲/柏林时区，而 CET 是正确的。 

有人知道如何手动添加新版本的 tzdata2020d 数据库，该数据库可在此处获得。

我用 Go 编写的应用程序在 2020 年 10 月 31 日使用 tzdata2020c 错误地使用了欧洲/柏林的 CEST：

同一应用程序在 2020 年 10 月 31 日使用 tzdata2020a 正确使用了欧洲/柏林的 CET：

根据 Google，tzdata rpm 控制在系统级别应用的时区，而 tzdata-java 控制面向 Java 的应用程序（例如 openJDK、JRE）的时区。

我的困惑是..为什么java应用程序不使用系统级时区的系统级相关数据。为什么需要单独的 rpm tzdata-java 来更新时区？