Hide Forgot
Description of problem: The lack of the 2018g release makes machines unreliable time-wise for people living in countries where recent timezone changes have been legalised. See the upstream release notes for details. Version-Release number of selected component (if applicable): All releases before the 2018g one. Expected results: Update the Fedora package to match the upstream release.
A trivial upgrade of spec results in FTBFS: + java -classpath javazic-1.8 build.tools.tzdb.TzdbZoneRulesCompiler -srcdir . -dstfile tzdb.dat -verbose africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera backward javazic-1.8/tzdata_jdk/gmt javazic-1.8/tzdata_jdk/jdk11_backward Compiling TZDB version 2018g Parsing file: ./africa Parsing file: ./antarctica Parsing file: ./asia Failed: java.lang.Exception: Failed while parsing file './asia' on line 1655 'Rule Japan 1948 1951 -Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file './asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at build.tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:365) at build.tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:186) at build.tools.tzdb.TzdbZoneRulesCompiler.main(TzdbZoneRulesCompiler.java:91) Caused by: build.tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at build.tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at build.tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at build.tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:463) at build.tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:387) at build.tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:342) ... 2 more This seems like javazic-1.8 needs updating but that seems to be like osm packaging woodoo.
javazic-1.8 from latest commit 478a4add975b doesn't make a difference.
It looks like javazic needs to grow brains to handle 25:00 as 1:00 of the next day: +# This instruction is equivalent to "Sat>=8 25:00", so use that. zic treats +# it like "Sun>=9 01:00", which is not quite the same but is the best we can +# do in any POSIX or C platform. The "25:00" assumes zic from 2007 or later, +# which should be safe now. Fixing javazic is of course preferable, but in the meantime, the following should help: diff -up tzdata-2018g/asia\~ tzdata-2018g/asia --- tzdata-2018g/asia~ 2018-10-03 02:21:28.000000000 +0200 +++ tzdata-2018g/asia 2018-11-12 13:00:57.906616697 +0100 @@ -1653,7 +1653,7 @@ Zone Asia/Jerusalem 2:20:54 - LMT 1880 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Japan 1948 only - May Sat>=1 24:00 1:00 D -Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S +Rule Japan 1948 1951 - Sep Sat>=9 01:00 0 S Rule Japan 1949 only - Apr Sat>=1 24:00 1:00 D Rule Japan 1950 1951 - May Sat>=1 24:00 1:00 D
Thanks. A PR: https://src.fedoraproject.org/rpms/tzdata/pull-request/2
Hello, As you are aware, the upstream project has introduced the use of 25:00 as part of the data format. This currently breaks the java portion of the tzdata build. After some discussion, we have decided to continue to use main/default format for the f29 tzdata builds. However, for the java portion of the build, we will use the rearguard format until java is able to handle the format change. I will be working on this today. My apologies for the delay. Patsy
tzdata-2018g-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-529994a55a
(In reply to Patsy Franklin from comment #5) > Hello, > > As you are aware, the upstream project has introduced the use of 25:00 as > part of the data format. This currently breaks the java portion of the > tzdata build. > > After some discussion, we have decided to continue to use main/default > format for the f29 tzdata builds. However, for the java portion of the > build, we will use the rearguard format until java is able to handle the > format change. > > I will be working on this today. > > My apologies for the delay. > Patsy Thanks for looking into this.
tzdata-2018g-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7d685d4be7
tzdata-2018g-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-01a5c99929
tzdata-2018g-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7d685d4be7
tzdata-2018g-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-529994a55a
The version in testing works for me, thanks for the fix. I'm closing the ticket, please reopen if that is not the right step.
tzdata-2018g-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
tzdata-2018g-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-01a5c99929
tzdata-2018g-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.