[tz] Java & Rearguard

[Paul Eggert]

Stephen Colebourne wrote:

> With Java, it is wrong to assume that the documented API is the only
> issue when considering a change.

Yes, other issues should be considered. However, the fact that the documented 
Java API provides for negative DST does suggest the solution of having the Java 
implementation provide for negative DST.

> * that both ways of describing the data are valid

Not by some reasonable everyday definitions of "valid". The current Java 
approach requires Irish Standard Time (IST) to not be standard time in Ireland, 
which is contrary to the intent of the relevant Irish legislation and to common 
practice in Ireland.

> * that tzdb made a choice to describe the data in terms of negative SAVE values

Quite true.

> * that by doing so tzdb had painful implications for downstream projects

There doesn't seem to be that much pain in practice, as indicated by major 
software distributions running successfully with IST being standard time for the 
past year or more. Any remaining issues can be shaken out as needed.

> what I'm looking for is a long term
> commitment that "make rearguard_tarballs" will continue to exist even
> if the tarball is not distributed

I plan to continue to maintain "make rearguard_tarballs" for the next release 
and I have no plans to remove this feature. However, "long term commitment" goes 
too far. The "Interface stability" of the Theory page does not constrain the 
Makefile that tzdb distributes, and I'd rather not add a constraint for this 
particular issue; among other things, any such constraint would be hard to document.

If TZUpdater needs a particular format, TZUpdater should take on the burden of 
maintaining code to translate from the current format to the format that it 
needs. Better, though, would be for TZUpdater to handle the current format, 
which has been supported by tzdb since 2007 so it's not like we're rapidly 
adding new features here.