[tz] Java & Rearguard

[Stephen Colebourne]

On Sat, 1 Jun 2019 at 18:59, Paul Eggert <eggert at cs.ucla.edu> wrote:
> > [The Java documentation] doesn't explicitly claim that the savings
> > is positive
>
> Yes, that was a real eye-opener to me. It means the Java developers could add
> negative-DST support to Java without changing Java's documented API. From my
> point of view it's a bug fix that's needed for POSIX compatibility anyway.

With Java, it is wrong to assume that the documented API is the only
issue when considering a change. Behavioural compatibility is also
considered. I've also pointed out that the code documents the value
for DST_OFFSET to be from 00:00 to 02:00 in the older time-zone code.
And other parts of the API rely on the DST flag being true in summer.

I've also indicated that there is no desire to support full POSIX:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4263805

As I, and others, have said, I don't believe there is any appetite to
change the meaning of DST in Java - the pain would be far too great
with no or negative benefits.

What is unfortunate is the lack of desire to engage on the substantive point:
* that both ways of describing the data are valid
* that tzdb made a choice to describe the data in terms of negative SAVE values
* that by doing so tzdb had painful implications for downstream projects
As Mark and I have indicated, we simply believe the wrong choice was
made by tzdb - the data should be expressed using positive SAVE values
with the legal situation expressed in the comments.

Given where we are, and the seeming unwillingness of tzdb to change
back to positive SAVE values, 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. Downstream projects need certainty
here to determine what course of action to take.

Stephen