[tz] Java & Rearguard

Paul Eggert eggert at cs.ucla.edu
Sat Jun 1 17:59:33 UTC 2019


Stephen Colebourne wrote:

> JDK only really handles identifiers like Europe/Dublin.

JDK does handle the POSIX-format TZ setting TZ='MST7', even though MST7 is not a 
tzdb Zone name, so it appears that JDK already supports POSIX-format TZ settings 
that lack daylight saving rules.

> I have't see much evidence that Java
> developers think the lack of support of the POSIX string is a problem.
Perhaps they'll think it's a problem after reviewing this discussion thread. Had 
Java been upward-compatible with POSIX-format TZ settings all along, then we 
would likely have avoided this compatibility mess. When POSIX came out in 1988 
tzdb was not 100% upward-compatible with POSIX, but we changed tzdb long ago to 
make it compatible and Java surely can do the same.
> What differs is the value returned by ZoneRules:

Yes, it appears that Fedora does the following:

1. Install tzdb's main-format .zi and TZif files, so that most programs think 
Ireland has negative DST.

2. Install openjdk's time zone data generated from rearguard-format .zi files, 
so that Java programs think Ireland has positive DST.

The two methods agree everywhere, in that all Irish timestamps have the same UTC 
offset, the same "IST"/"Irish Standard Time" names, etc.; *except* that the two 
methods disagree about the DST flag (tm_isdst in the POSIX model, 
isDaylightSavings in the Java model). This discrepancy is so minor that it 
apparently doesn't matter. As Robert Elz writes, programmers shouldn't rely on 
the DST flag anyway (for other reasons), and we can simply add the Ireland 
glitch to the list of reasons that programmers should avoid the DST flag.

Of course it would be nice for Java and tzdb to agree about the DST flag warts 
and all, and I suggest that the Java folks do so when they fix Java's 
mishandling of POSIX-format TZ strings. But this apparently isn't crucial since 
we've known about the problem for some time and systems are being delivered with 
this minor DST-flag discrepancy without major problems.

> [The Java documentation] doesn't explicitly claim that the savings
> is positive

Yes, that was a real eye-opener to me. It means the Java developers could add 
negative-DST support to Java without changing Java's documented API. From my 
point of view it's a bug fix that's needed for POSIX compatibility anyway.

> The rearguard format is needed as the input to TZUpdater

If that's the problem, it can be addressed by fixing TZUpdater. Even if the Java 
developers want to outlaw negative DST (which in my view would be a mistake, 
because Java would be incompatible with POSIX), they could change TZUpdater to 
do the equivalent of ziguard.awk to translate the input into rearguard form 
before continuing to process the input. Better, though, would be to be 
upward-compatible with POSIX and allow negative DST; i.e., the Java developers 
could modify TZUpdater to support negative DST consistently with Java's 
longstanding API and documentation.

> The purpose of this thread from my perspective is mainly to highlight
> that the data we extract from rearguard is going to be needed forever.

It'll be needed "forever" by TZUpdater only if the Java developers adopt the 
hack where TZUpdater generates the rearguard format internally, and at that 
point it's TZUpdater's responsibility to keep the rearguard format going. I 
suggest, though, that TZUpdater be modified to support negative DST since 
negative DST is needed for POSIX compatibility anyway.



More information about the tz mailing list