Metazone timestamps

[Matt Johnson (AZURE) via CLDR-Users]

Ticket filed here.  Thanks.
https://unicode.org/cldr/trac/ticket/10742


From: Yoshito Umaoka [mailto:yoshito_umaoka at us.ibm.com]
Sent: Wednesday, November 1, 2017 8:31 AM
To: Matt Johnson (AZURE) <matt.johnson at microsoft.com>
Cc: cldr-users at unicode.org
Subject: Re: Metazone timestamps

> In http://www.unicode.org/reports/tr35/tr35-dates.html#Metazone_Names<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.unicode.org%2Freports%2Ftr35%2Ftr35-dates.html%23Metazone_Names&data=02%7C01%7Cmatt.johnson%40microsoft.com%7C18594b044ade4724393808d5213d889d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451470532695497&sdata=0kfymJVcSpfQgI3KSZPHhJqDjOglvs4Kx1gw1YwPRBo%3D&reserved=0>
> there is an example:
>
> <timezone type="America/Indiana/Knox">
>   <usesMetazone to="1991-10-27 07:00" mzone="America_Central"/>
>   <usesMetazone to="2006-04-02 07:00" from="1991-10-27 07:00"
> mzone="America_Eastern"/>
>   <usesMetazone from="2006-04-02 07:00" mzone="America_Central"/>
> </timezone>
>
> It also states: “Note that the dates and times are specified in UTC,
> not local time.”
>

Correct.

> As currently presented, they appear to be local time.  Is there a
> reason these aren't just expressed as ISO 8601 timestamps with a
> trailing Z?  In other words:  “1991-10-27T07:00Z”
>
> Note that ISO 8601 allows for a space instead of a T, so these
> timestamps are ISO 8601 compliant, but also that in absence of a Z
> or an offset they are required to be interpreted as local time.

I guess the original author/designer of this data did not really care about ISO 8601 conformance.

> I’ve certainly made this mistake in interpreting them before.  I’m
> sure others have as well.  Would it be possible to change this in a
> future version?
>

I actually felt the same when I started maintaining the data.
Personally, I'm fine to change the date/time string to be ISO UTC time format (and use the default date/time separator - 'T'), then update the spec to explain it's ISO 8601 UTC date/time format explicitly.

But, this change may break existing code utilizing this data, so we probably need to discuss this in CLDR TC.

Anyway, can you file a CLDR ticket?


> Thanks,
> Matt Johnson
> Microsoft
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20171101/1dd27387/attachment.html>