问题描述

我正在尝试使用 TZUpdater 2.2.0.

> [root@local tzupdater-2.2.0]# java -jar tzupdater.jar -V
  tzupdater version 2.2.0-b01
  JRE tzdata version: tzdata2018d
  tzupdater tool would update with tzdata version: tzdata2018f

所以，我正在运行以下命令:

So, I'm running the command below:

> [root@local tzupdater-2.2.0]# java -jar tzupdater.jar -l

但是，我收到以下错误消息:

However, I'm getting this error message:

Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_1/asia' on line 1655 'Rule  Japan   1948    1951    -   Sep Sat>=8  25:000S'
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_1/asia' on line 1655 'Rule  Japan   1948    1951    -   Sep Sat>=8  25:00   0   S'
    at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377)
    at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191)
    at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307)
    at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153)
    at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230)
    at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634)
Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000
    at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173)
    at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210)
    at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475)
    at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399)
    at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354)
    ... 5 more

我正在使用 https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz 作为 tzdata 包的来源.

I'm using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as the source for the tzdata bundle.

已编辑 - 此外，我正在使用 Java(TM) SE 运行时环境(内部版本 1.8.0_66-b17)和 OpenJDK 运行时环境(内部版本 1.8.0_181-8u181-b13-1~deb9u1-b13)，同时我使用 TZUpdater 或 ZIUpdater

Edited - In addition, I'm using either Java(TM) SE Runtime Environment (build 1.8.0_66-b17) and OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13), meanwhile I have same reported problem using TZUpdater or ZIUpdater

谁能帮我解决这个问题?任何意见将不胜感激.

Can anyone help me about this issue? Any comment will be appreciated.

非常感谢.

推荐答案

是的，1948-1951 年日本的规则在 2018 年以一种有趣"的方式发生了变化:官方说，日本的倒退发生在周六 25:00，而不是周日的 01:00.这让 Java 时区更新程序以及我自己的 Noda Time 项目感到困惑.

Yes, the rules for Japan in 1948-1951 changed in 2018f in an "interesting" way: officially, Japan's fall back occurred at 25:00 on Saturday, instead of 01:00 on the Sunday. That confused the Java time zone updater, as well as my own Noda Time project.

现在有一个承诺以后卫"格式避免25:00 -后卫格式基本上比较保守，避免像爱尔兰的负夏令时.

There's now a commit to avoid 25:00 in the "rearguard" format - the rearguard format is basically more conservative, avoiding things like Ireland's negative DST.

我预计 2018g 版本很快就会发布，包含该修复程序.假设 tzupdater 工具适当地使用后卫，我希望它能解决问题.如果你能等到那个时候，我会这样做.否则，使用 tzupdater 上的 -l 标志来指定不同的数据源，例如对于 2018e:https://data.iana.org/time-zones/发布/tzdata2018e.tar.gz

I would expect a 2018g release at some point reasonably soon, to include that fix. Assuming the tzupdater tool uses the rearguard appropriately, I'd expect that to sort things out. If you can possibly wait until then, I'd do so. Otherwise, use the -l flag on tzupdater to specify a different data source, e.g. for 2018e: https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz