Why exactly does Java not want to implement a parser that supports the current version of the tz database? It seems like they should either make the case for why negative DST is not a good feature to support, or they should adjust to the fact that it is a feature that will be present in the time zone database.

I do not think it is a reasonable thing to ask the tz project to maintain compatibility data indefinitely. The whole point of the rearguard format was as a courtesy to slow-moving projects that may have baked invalid assumptions into their already-deployed software. It seems very rude to me to deliberately not take advantage of this opportunity to fix the problems with their software on the assumption that the maintenance burden can be shifted onto the tz project.

Best,
Paul

On 5/29/19 10:34 AM, Stephen Colebourne wrote:
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