[tz] Java & Rearguard

[Paul Eggert]

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.