[tz] Java & Rearguard

Mark Davis ☕️ mark at macchiato.com
Mon Jun 10 11:39:08 UTC 2019

> This is because until October last year, +00
was standard time and +01 was daylight saving time in Morocco, but now it's
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").


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>

More information about the tz mailing list