Internationalization: Support for IANA time zones

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Tue Mar 5 12:26:33 PST 2013


On Mar 4, 2013, at 22:49 , L. David Baron wrote:

> On Saturday 2013-03-02 10:50 -0800, Norbert Lindenberg wrote:
>> On Mar 2, 2013, at 8:46 , Mark Davis ? wrote:
>>> The TZDB has the equivalence class {Asia/Calcutta Asia/Kolkata}. They used to have the former as the canonical name (in Zone), but then changed it to the latter. Here is the current TZDB data:
>>> 
>>> zone.tab
>>> 
>>> IN	+2232+08822	Asia/Kolkata
>>> 
>>> asia
>>> 
>>> Zone	Asia/Kolkata	5:53:28 -	LMT	1880	# Kolkata
>>> ...
>>> 
>>> backward
>>> Link	Asia/Kolkata		Asia/Calcutta
>>> 
>>> Because of the Link, both are valid and equivalent.
> 
>> That breaks if/when the tz database removes Asia/Calcutta from its Link list and other systems using IANA names stop supporting (or never start supporting) that name.
>> 
>> I still think the stability issue should be addressed in the IANA time zone database itself, not by adopting a IANA-derived alternate registry. Has that been tried?
> 
> In http://mm.icann.org/pipermail/tz/2013-March/018697.html the
> maintainer of the timezone database wrote (in reference to this
> discussion):
>  # That discussion seems to be predicated on the assumption that
>  # tz zone names can and do "disappear", but they don't.  For example,
>  # we renamed Asia/Calcutta to Asia/Kolkata, but kept the old name
>  # as an alias for the new one.
> 
> So I think from their end, the "stability issue" is considered
> addressed.  Is that not sufficient?

Depends on how explicit that stability guarantee is. In the meantime I learned from the ongoing discussion that there is a Theory file, tucked away in the tzcode tar ball, that includes some rules. I proposed making that information a bit more prominent, e.g., in the form of an RFC.
http://mm.icann.org/pipermail/tz/2013-March/018714.html

Norbert



More information about the es-discuss mailing list