On 5/29/19 9:05 AM, Paul Ganssle wrote:
Why exactly does Java not want to implement a parser that supports the current version of the tz database? It seems like they should either make the case for why negative DST is not a good feature to support, or they should adjust to the fact that it is a feature that will be present in the time zone database.
As I vaguely understand it, the difficulty is not merely in fixing the TZUpdater parser, it's that the Java library code internally mishandles negative DST offsets. So, if TZUpdater were changed simply to pass negative DST offsets through, this would cause trouble in production instances of Java relying on current or older libraries, just as setting TZ='IST-1GMT0,M10.5.0,M3.5.0/1' in the environment presumably causes trouble in production instances of Java. (That TZ setting exercises the support for negative DST that's been standardized by POSIX since 1988.) If I'm right, one workaround would be for TZUpdater to compute the most negative DST offset in use for a zone, and treat that offset as standard time while treating the other DST offsets as daylight-saving time. That way, TZUpdater's output would contain only nonnegative DST offsets and the Java library code would be happy. I don't see anything in the current Java standard API that prohibits negative DST offsets, and a cursory look at the code for the Java standard library doesn't reveal any problems either, so I guess the problem with negative offsets is deep in the Java library implementation. Or perhaps the problem doesn't exist in the current API and/or library, but does exist in older versions. I could well be wrong about all this, though, as I don't use the Java timezone API or code.