Matt Johnson (AZURE) via CLDR-Users
cldr-users at unicode.org
Wed Nov 1 14:47:40 CDT 2017
Ticket filed here. Thanks.
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"
> <usesMetazone from="2006-04-02 07:00" mzone="America_Central"/>
> It also states: “Note that the dates and times are specified in UTC,
> not local time.”
> 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?
> Matt Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CLDR-Users