> This is because until October last year, +00 
was standard time and +01 was daylight saving time in Morocco, but now it's the 
other way around.

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.

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 or for it.

For each <zone, locale> pair that has 2 offsets* within a year, all CLDR has and needs, is:

(a) a name for the "less advanced" offset, and 
(b) a name for the "most advanced offset",
(c) a name for "wall time" (generic).

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

{phone}

On Sun, Jun 9, 2019, 18:57 Paul Eggert <eggert@cs.ucla.edu> wrote:
Mark Davis ☕️ wrote:
> We have not seen any demand for names before 1970

The overall problem is not limited to names before 1970. It has occurred as
recently as yesterday in Morocco. This is because until October last year, +00
was standard time and +01 was daylight saving time in Morocco, but now it's the
other way around.

I presume that Morocco is low priority for Java+CLDR, as this change has not
found its way into CLDR+Java yet. OpenJDK 12.0.1's data for Morocco has not been
updated since Morocco last changed its rules, and OpenJDK mishandles UTC offsets
for Moroccan timestamps as recent as yesterday, as shown in the example at the
end of this email.

Java+CLDR can get away with a low priority for Morocco, as Morocco is a small
part of the market. But it's likely that the issue can't continue to be ignored
if North America and/or Europe change their zones as they are threatening to do
soon. To some extent Morocco is a canary in the coal mine here, as it jumped the
gun on the upcoming EU DST changes.

   $ jshell
   |  Welcome to JShell -- Version 12.0.1
   |  For an introduction type: /help intro

   jshell> var zone = java.time.ZoneId.of("Africa/Casablanca")
   zone ==> Africa/Casablanca

   jshell> var time = java.time.Instant.ofEpochSecond(1560011295)
   time ==> 2019-06-08T16:28:15Z

   jshell> var dtf = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd
HH:mm:ss Z z (zzzz)")
   dtf ==> Value(YearOfEra,4,19,EXCEEDS_PAD)'-'Value(MonthOf ... RT)'
''('ZoneText(FULL)')'

   jshell> time.atZone(zone).format(dtf)
   $4 ==> "2019-06-08 17:28:15 +0100 WET (Western European Standard Time)"

   jshell>

   $ TZ=Africa/Casablanca LC_ALL=C date -d@1560011295
   Sat Jun  8 16:28:15 +00 2019

The last line (from tzdb) is correct. In contrast, the Java-generated line
"17:28:15 +0100 WET (Western European Standard Time)" is wrong by an hour and
its UTC offset is miscalculated as +01, despite the fact that Java's name for
the time zone is OK because WET is conventionally an alias for +00.