[tz] Java & Rearguard

[Paul Eggert]

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?