<div dir="ltr"><div dir="auto"><div class="gmail_default" style="font-family:"times new roman",serif">> <span style="font-family:Arial,Helvetica,sans-serif">This is because until October last year, +00</span><span style="font-family:Arial,Helvetica,sans-serif"> </span></div>was standard time and +01 was daylight saving time in Morocco, but now it's the <br><div class="gmail_default" style="font-family:"times new roman",serif"><span style="font-family:Arial,Helvetica,sans-serif">other way around.</span></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">I think we were talking about different things. I thought you were talking about the zones that had multiple offsets, so that's what I responded to. Sorry for the confusion.</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">As for the "inverted" daylight savings that was introduced a couple of years ago (for Ireland, now Morocco), I don't consider that an architectural improvement, and there is no need to change CLDR to it <i>or</i> for it.</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">For each <zone, locale> pair that has 2 offsets* within a year, all CLDR has and needs, is:</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">(a) a name for the "less advanced" offset, and </div><div class="gmail_default" style="font-family:"times new roman",serif">(b) a name for the "most advanced offset",</div><div class="gmail_default" style="font-family:"times new roman",serif">(c) a name for "wall time" (generic).</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">For historic reasons, (a) has the *internal* id of 'standard', and (b) has the *internal* id of 'daylight', but there is no requirement whatsoever that the translated names reflect the internal ids (many locales use the equivalent of "Winter Time" and "Summer Time").<br></div><br><div data-smartmail="gmail_signature">{phone}</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 9, 2019, 18:57 Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">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">Mark Davis ☕️ wrote:<br>
> We have not seen any demand for names before 1970<br>
<br>
The overall problem is not limited to names before 1970. It has occurred as <br>
recently as yesterday in Morocco. This is because until October last year, +00 <br>
was standard time and +01 was daylight saving time in Morocco, but now it's the <br>
other way around.<br>
<br>
I presume that Morocco is low priority for Java+CLDR, as this change has not <br>
found its way into CLDR+Java yet. OpenJDK 12.0.1's data for Morocco has not been <br>
updated since Morocco last changed its rules, and OpenJDK mishandles UTC offsets <br>
for Moroccan timestamps as recent as yesterday, as shown in the example at the <br>
end of this email.<br>
<br>
Java+CLDR can get away with a low priority for Morocco, as Morocco is a small <br>
part of the market. But it's likely that the issue can't continue to be ignored <br>
if North America and/or Europe change their zones as they are threatening to do <br>
soon. To some extent Morocco is a canary in the coal mine here, as it jumped the <br>
gun on the upcoming EU DST changes.<br>
<br>
$ jshell<br>
| Welcome to JShell -- Version 12.0.1<br>
| For an introduction type: /help intro<br>
<br>
jshell> var zone = java.time.ZoneId.of("Africa/Casablanca")<br>
zone ==> Africa/Casablanca<br>
<br>
jshell> var time = java.time.Instant.ofEpochSecond(1560011295)<br>
time ==> 2019-06-08T16:28:15Z<br>
<br>
jshell> var dtf = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd <br>
HH:mm:ss Z z (zzzz)")<br>
dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)' <br>
''('ZoneText(FULL)')'<br>
<br>
jshell> time.atZone(zone).format(dtf)<br>
$4 ==> "2019-06-08 17:28:15 +0100 WET (Western European Standard Time)"<br>
<br>
jshell><br>
<br>
$ TZ=Africa/Casablanca LC_ALL=C date -d@1560011295<br>
Sat Jun 8 16:28:15 +00 2019<br>
<br>
The last line (from tzdb) is correct. In contrast, the Java-generated line <br>
"17:28:15 +0100 WET (Western European Standard Time)" is wrong by an hour and <br>
its UTC offset is miscalculated as +01, despite the fact that Java's name for <br>
the time zone is OK because WET is conventionally an alias for +00.<br>
</blockquote></div>