[tz] Java & Rearguard

Stephen Colebourne scolebourne at joda.org
Wed May 29 14:34:01 UTC 2019

On Tue, 28 May 2019 at 17:19, Paul Eggert <eggert at 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


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


More information about the tz mailing list