Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1646930 - The current version lags behind the upstream's.
Summary: The current version lags behind the upstream's.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: tzdata
Version: 29
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Patsy Griffin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-06 10:39 UTC by E.N.
Modified: 2018-11-21 03:11 UTC (History)
5 users (show)

Fixed In Version: tzdata-2018g-1.fc29 tzdata-2018g-1.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-13 20:58:08 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description E.N. 2018-11-06 10:39:37 UTC 
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.
Comment 1 Miro Hrončok 2018-11-11 08:51:16 UTC 
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.
Comment 2 Miro Hrončok 2018-11-11 09:10:44 UTC 
javazic-1.8 from latest commit 478a4add975b doesn't make a difference.
Comment 3 Petr Machata 2018-11-12 12:05:30 UTC 
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
Comment 4 Miro Hrončok 2018-11-12 12:15:51 UTC 
Thanks.

A PR: https://src.fedoraproject.org/rpms/tzdata/pull-request/2
Comment 5 Patsy Griffin 2018-11-12 13:38:38 UTC 
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
Comment 6 Fedora Update System 2018-11-12 22:21:26 UTC 
tzdata-2018g-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-529994a55a
Comment 7 E.N. 2018-11-12 22:50:14 UTC 
(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.
Comment 8 Fedora Update System 2018-11-12 23:04:07 UTC 
tzdata-2018g-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7d685d4be7
Comment 9 Fedora Update System 2018-11-13 00:14:21 UTC 
tzdata-2018g-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-01a5c99929
Comment 10 Fedora Update System 2018-11-13 04:08:03 UTC 
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
Comment 11 Fedora Update System 2018-11-13 04:50:16 UTC 
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
Comment 12 E.N. 2018-11-13 20:58:08 UTC 
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.
Comment 13 Fedora Update System 2018-11-14 03:12:42 UTC 
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.
Comment 14 Fedora Update System 2018-11-14 04:57:19 UTC 
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
Comment 15 Fedora Update System 2018-11-21 03:11:37 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.