[tz] [english 100%] Re: Irish Standard Time vs Irish Summer Time

[Paul Eggert]

On 01/18/2018 01:36 PM, Meno Hochschild wrote:
> I also suspect that this is another problem (not yet tested): Java 
> would start with v2018a to report Irish Summer Time (IST) in winter 
> and GMT in summer when it comes to formatting the Irish zone 
> Europe/Dublin.

Yes, it sounds quite plausible that Java/OpenJDK would somehow translate 
"IST" to "Irish Summer Time" in Europe/Dublin. This assumption has been 
incorrect for quite some time, as for many years tzdata's Europe/Dublin 
has used "IST" to stand for "Irish Standard Time" for some timestamps 
(notably, between 1968 and 1971). Unfortunately the tzdata format does 
not allow this assumption to be stated in the data; it's only in 
comments. If the Java/OpenJDK model does not allow the same abbreviation 
("IST" in this case) to mean different things at different times in the 
same location, that would be a shortcoming in the model regardless of 
whether the Irish data moves to timestamps with negative DST offsets.

Java/OpenJDK is a different project from tzcode, and it has always 
supported a superset-of-a-subset of what tzcode supports. For example, 
Java (at least, Oracle's version of Java) does not support POSIX-format 
TZ settings; on the other hand, Java supports long names like "Pacific 
Standard Time" that tzcode does not. With that in mind, it would be 
understandable if Java/OpenJDK decides not to support negative DST 
offsets; it would be just one more thing in the list of things that 
tzcode has but Java lacks. If that happens, it should be possible for 
Java-based readers of tzdata source files to automatically translate 
negative DST offsets into positive ones (switching abbreviations of 
course), as I think Stephen Colebourne suggested. It's also possible 
that all things considered it would be better if Java supported negative 
DST offsets -- but that's not our call to make.

We can give the Java folks some time to prepare for this by backing out 
the Irish changes for now. We can bring the changes back in the 
not-too-distant future, and in the meantime the Java folks can test 
their fixes on 2018b.