[tz] Java & Rearguard
Paul Ganssle
paul at ganssle.io
Wed May 29 16:05:08 UTC 2019
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 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190529/e55d8ed6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20190529/e55d8ed6/attachment.sig>
More information about the tz
mailing list