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.