[tz] Recommendations for stable list of timezone ids

Mark Davis ☕️ mark at macchiato.com
Fri Feb 9 13:36:22 UTC 2018


Here is the info:

http://unicode.org/reports/tr35/tr35.html#Time_Zone_Identifiers

Hmmm. Just saw a typo there ... oh, well.

Every time we import the TZDB, we check the zone.tab file for changes.

Mark

On Fri, Feb 9, 2018 at 2:24 PM, Tobias Lindaaker <thobes at gmail.com> wrote:

> Thank you Mark.
>
> Is this the list you refer to: http://unicode.org/repos/
> cldr/trunk/common/bcp47/timezone.xml ?
> Does this list have a stable order such as the one I described? - it looks
> like it is order alphabetically by the name.
> Could you share any details on how you compile it and keep it up to date?
>
> Cheers,
> Tobias
>
> On 9 Feb 2018, at 13:52 , Mark Davis ☕️ <mark at macchiato.com> wrote:
>
> In CLDR we have had to produce a stable set of TZIDs as well, so you might
> look at that. (We also have to have short IDs, so we developed those based
> where possible on UNLOC codes.)
>
> Mark
>
> On Fri, Feb 9, 2018 at 1:44 PM, Tobias Lindaaker <thobes at gmail.com> wrote:
>
>> I am trying to compile a flat list of all tzids in the Time Zone Database
>> in a way such that the position of a tzid remains the same in the list even
>> in the face of future changes to the Time Zone Database.
>>
>> I would like to know if anyone could provide me with some insight into
>> how (a prefix of) such a list could be generated from any version of the
>> Time Zone Database. Or would this be something I would have to maintain
>> myself from release to release of the Time Zone Database?
>>
>> The requirements I would have for generating this list would be that
>> given two releases of the Time Zone Database, X and Y. If X is released
>> before Y, then the list generated from X must be a prefix of the list
>> generated from Y (and vice versa: if Y is released before X, the list
>> generated from Y must be a prefix of the list generated from X).
>>
>> A simple alphabetical ordering is obviously not going to work, since for
>> example the addition of America/Punta_Arenas in 2017a would end up before
>> many of the tzids that existed in versions prior.
>>
>> Since I don't require this to work for all historical releases, my first
>> thought was to start from a fairly recent release (tzdata2013h) and verify
>> that I got the same order when sorting the timezones based on their
>> earliest rule. However the removal of tzids (such as
>> Canada/East-Saskatchewan in tzdata2017c) made this impossible, since any
>> removal makes it impossible to ensure that prior versions are strict
>> prefixes.
>>
>> It now seems as if I would have to maintain this list myself, tracking
>> each release of the Time Zone Database and ensure that any tzids added to
>> the Time Zone Database are appended to my list in release order. If
>> possible I would very much prefer to avoid this, since it requires me to
>> release updates of my software to track the releases of the Time Zone
>> Database, I would much rather like it if my software could rely on the Time
>> Zone Database available from the system where it was running.
>>
>> Finally some background on why (I think) I need to generate this type of
>> list of tzids: I am improving the support for storing timestamp values in a
>> database management system (Neo4j), and would like to avoid having to store
>> the timezone component of zoned timestamps as a (variable length) text
>> component, but rather store it as a fixed size integer offset into a table
>> of tzids. Thus I need such a stable list of tzids.
>>
>> I have tried searching the archives of this mailing list for similar
>> questions before posting, but have not been able to find such an entry. The
>> closest I found were a few questions on how to translate the tzids to
>> localized names. Since I did not read through the entire archives, but only
>> did a search, I apologise in advance if this has been asked and solved
>> before, and hope that you will be able to direct my attention to that
>> thread.
>>
>> Thank you,
>> Tobias
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180209/f87c55b8/attachment.html>


More information about the tz mailing list