[tz] Java & Rearguard
eggert at cs.ucla.edu
Wed May 29 17:38:44 UTC 2019
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.
More information about the tz