On Tue, 28 May 2019 at 17:19, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/27/19 1:48 PM, Paul Goyette wrote:
Is the current rearguard format expected to live "forever"?
No, the idea is only that it's rearguard "enough". That is, even the rearguard is on the march, and every announcement of the publication of the rearguard-format tarballs has said that they're intended to be temporary.
The next release (2019b, which should be reasonably soon) may be a good time to skip my publication of a rearguard-format tarball. The main use of the rearguard format seems to be last-minute updates for people using TZUpdater and the like, and we'll almost surely have a release 2019c before October anyway so people can update then. People who need rearguard format tarballs before then can make them by running "make rearguard_tarballs".
So, the needs of Java-based libraries have not fundamentally changed since tzdb first started making changes. It is still the case that Java libraries do not want negative DST, and my expectation is that this will always be true. If this means using rearguard forever and shouting about attempts to remove it then so be it. A hack was added to Joda-Time that reverses negative SAVE values which works so long as a rule set does not mix positive and negative save values. This is pretty awful as an approach because it is unreliable. The same hack has not yet been added to ThreeTen-Backport or OpenJDK itself, with both still using rearguard. I can't comment directly on other Java libraries. Joda-Time and ThreeTen-Backport now parse and handle 25:00 as a cutover time. I don't think the associated OpenJDK issue has been fixed. --- Perhaps a discussion could be had on a way to represent the data that Java needs alongside the main data, so that Java parsers can avoid the nasty hack? And remove the need for both hacks and rearguard? Proposal: Add an additional file with legacy versions of the rules that cause problems to downstream parsers. Thus, add a new file "legacy" that contains an alternate version of "Eire" and "Europe/Dublin" (ones with positive DST). Note that the complete set of Rule and Zone lines would be added to legacy, so it could be parsed in its own right as a tzdb source file. I would expect that most parsers would simply ignore the extra file (the main reason for doing it this way). But Java (and other) parsers could choose to parse it and overwrite the negative DST definitions (a much simpler and safer process than the hack that has been added so far). Stephen