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

[Yoshito Umaoka]

> 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.
> 

I'm maintaining time zone data in CLDR and implementation in ICU.

In ICU implementation, supporting negative DST offset in a new version
is not difficult at all (only a few line of changes).

A bigger problem is that we currently distribute only time zone data
(in ICU consumable format) for updating older ICU releases. There are
many ICU consumers who want the latest time zone data, but do not want
to change anything else. Releasing a code patch for every past versions
is a hassle for us too. I think Java folks are in the same situation.


> 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.
> 

Java also imports time zone display name data from CLDR (BTW, CLDR uses
"Irish Standard Time" as the long name). CLDR project cannot easily
swap names for standard time and daylight saving time, because we also
have many data consumers in various different implementations. Such
change will definitely break our downstream consumers. I guess CLDR
would just stay with the current (GMT as standard time, IST as daylight
saving time) forever.

In ICU, because we don't want to break ICU tz data backward compatibility,
I decided to modify 2018a Europe/Dublin to swap standard time and
daylight saving time, so we don't need to change localized display name
data in many languages at least for now. Even ICU code is ready to support
negative DST offsets, we may continue to swap standard/daylight for
Europe/Dublin.

-Yoshito Umaoka (Unicode CLDR/ICU)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180119/249440b6/attachment-0001.html>