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.