On Sat, 1 Jun 2019 at 18:59, Paul Eggert <eggert@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