<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">A couple of items.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">> <span class="gmail-il" style="font-family:Arial,Helvetica,sans-serif">CLDR</span><span style="font-family:Arial,Helvetica,sans-serif"> </span><span style="font-family:Arial,Helvetica,sans-serif">is trying to</span><span style="font-family:Arial,Helvetica,sans-serif"> </span><span style="font-family:Arial,Helvetica,sans-serif">maintain timezone strings that are suitable for Java (as almost nobody</span><span style="font-family:Arial,Helvetica,sans-serif"> </span></div>else uses them)<div><br></div><div><div class="gmail_default" style="font-family:"times new roman",serif">We don't know who all uses the timezone names from CLDR (and which flavor); they are the names used in ICU, which is in C, C++, and Java (with shims for other programming languages).</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">However, I agree that CLDR has misleading IDs for the different variants of a zone name: </div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">generic, standard, daylight.</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">While these are invisible to users, they can be misleading to programmers. Names that would have been more reflective of the intended use would have been something like:</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">generic, offset0, offset1<br></div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 5, 2019 at 10:41 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/5/19 3:51 AM, Stephen Colebourne wrote:<br>
> But it has been this way for 20+ years and isn't<br>
> going to change any time soon. It also produces an answer that as<br>
> correct as the underlying data (CLDR)<br>
<br>
I'm not sure it's fair to pass this buck to CLDR. CLDR is trying to <br>
maintain timezone strings that are suitable for Java (as almost nobody <br>
else uses them) and so if Java is messed up, CLDR will likely be equally <br>
messed up, to stay compatible with Java.<br>
<br>
Even now (that is, with rearguard format to pacify Java) there are still <br>
problems with time in Ireland due to Java's confusion on this issue (as <br>
mimicked by CLDR). See the example at the end of this email, where <br>
OpenJDK 12 says that local time should be called "GMT" / "Greenwich Mean <br>
Time" in Ireland on January 1, 1970, which is obviously wrong as Irish <br>
clocks were one hour ahead of UTC then (and Java gets the UTC offset <br>
right) and nobody on the ground then would have called that time "GMT".<br>
<br>
That being said, I'm not that pessimistic about whether these problems <br>
will be fixed. They are obviously fixable; all we need is for Oracle to <br>
do the fix in OpenJDK, and I'm sure that they can do it if they want to. <br>
In the meantime the problems do not seem to be that big a deal in practice.<br>
<br>
$ jshell<br>
|  Welcome to JShell -- Version 12.0.1<br>
|  For an introduction type: /help intro<br>
<br>
jshell> var epoch = java.time.Instant.EPOCH<br>
epoch ==> 1970-01-01T00:00:00Z<br>
<br>
jshell> var zone = java.time.ZoneId.of("Europe/Dublin")<br>
zone ==> Europe/Dublin<br>
<br>
jshell> var dtf = <br>
java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss Z z <br>
(zzzz)")<br>
dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)' <br>
''('ZoneText(FULL)')'<br>
<br>
jshell> epoch.atZone(zone).format(dtf)<br>
$4 ==> "1970-01-01 01:00:00 +0100 GMT (Greenwich Mean Time)"<br>
<br>
</blockquote></div>