[tz] Problem with some timezone data from 2023 w/ Java SimpleTimeZone

Paul Eggert eggert at cs.ucla.edu
Wed Jul 19 22:36:46 UTC 2023

On 2023-07-19 05:47, Andreas Haumer via tz wrote:
> See https://bugzilla.opensuse.org/show_bug.cgi?id=1213470 for my
> original bugreport]...
> So: is this a problem with the timezone database or rather a problem > with the implementation of the Java SimpleTimeZone class?
It's not clear whether the bug is in the program that generates tzdb.dat 
(in Fedora 38, the program that generates 
/usr/share/javazi-1.8/tzdb.dat), or in the Java library that reads 
tzdb.dat. I doubt whether it's a problem in tzdb itself. That is, it's 
somewhere in the Java code downstream.

I suspect the Java code is having trouble with Palestine's rule changes 
as first published in tzdb 2023a. Here are the lines that are probably 
causing problems:

   Rule Palestine 2058 max - Mar Sat<=30 2:00 1:00 S
   Rule Palestine 2075 max - Oct Sat<=30 2:00 0 -

These lines are a rough guess as to how Palestine's current DST rules 
would extend into the indefinite future. They cause zic to generate a 
TZif file (in Fedora 38, /usr/share/zoneinfo/Asia/Gaza) that ends with 
the following TZ string:


The two "50"s in this string rely on an extension to the POSIX.1-2017 TZ 
string format that has been supported and documented in tzdb since 
release 2013e, is standardized in Internet RFC 8536 (2019), and is in 
the POSIX.1-202x draft 3. My guess is that the Java code you're using is 
older and/or doesn't support this extension.

If I'm right, a simple workaround would be to remove the above two lines 
when generating tzdb.dat. Although this would cause timestamps to be 
more likely wrong starting in the year 2058, these timestamps are 
guesswork anyway. If you make that change, please add a comment saying 
what you're doing, and change the version number of the database to 
something like 2023c-suse1 so that people know you've made a change.

Better, of course, would be for downstream to fix whatever Java code is 
going awry. Quite possibly it's already fixed and you just need to 
upgrade to the most recent version of the Java code.

More information about the tz mailing list