[tz] Java & Rearguard
eggert at cs.ucla.edu
Fri May 31 22:49:34 UTC 2019
On 5/30/19 7:26 AM, Brandon Smith wrote:
> libraries and applications have forever been written based on the definition
> and understand that clocks move forward with DST transitions. I know it has
> been said that this is a 'bad assumption', but the reality as I see it is that
> generally speaking all software has been written based upon what developers
> knew to be a 'definition' and not an 'assumption' at all.
Although some libraries have been based on that assumption, it is certainly not
universal. On the contrary, IEEE Std 1003.1-1998 requires support for so-called
"negative DST", this requirement has remain unchanged from 1988 through the
current (2018) edition of POSIX, and a lot of software supports the POSIX model
for time zones. The problem we're facing is that (a) some non-POSIX-compatible
libraries have trouble with negative DST, and (b) details about what these
libraries actually do support remain unclear.
> I know it was alluded to that TZDB could perhaps use the next release to force
> the hand of the negative dst offset discussion (i.e. remove rearguard).
There's no intent to remove rearguard format in the next release. You'll still
be able to get rearguard format by running "make rearguard_tarballs", a command
that should run automatically if you have the right tools: basically a POSIX
environment and some freely-available portable programs like GNU tar.
The change I'm considering is merely to have downstream providers or users run
"make rearguard_tarballs" if they need rearguard tarballs. Part of the idea is
to simplify distribution and to make distribution errors less likely. Part of
the idea is to nudge downstream users of non-POSIX-compatible software to rely
on their upstream providers instead of having users individually deal with any
compatibility issues. And part of the idea is to encourage those who get data
directly from iana.org to use software that is compatible with the main data
format. The overall goal is to decouple downstream users from upstream changes,
so that we don't have to wait for all downstream users to upgrade before we can
install changes upstream. These are all worthy goals. Of course one must
consider both costs and benefits, but overall the next release seems like a good
time to try out a change like this.
> My company has not been able to adapt to the new negative offsets
What have been the obstacles, and what progress has been made so far? That is,
the problem has been publicized widely for well over a year; what's the rough
timeframe for your company's process for adapting to negative offsets?
More information about the tz