[tz] Java & Rearguard

[Mark Davis ☕️]

> 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190610/f9f8c453/attachment.html>