[tz] Recommendations for stable list of timezone ids

[Tobias Lindaaker]

Thank you Stephen,

That sounds very similar to what I want to achieve. Storing timestamps in UTC but tagging with origin zone is exactly what I am doing as well.
The C enum you describe, and the desire to use a fixed size small integer in storage is indeed the same as in my use case.
The changes you describe having made to zic don't quite sound like they would be useful to me, but I am curious to hear about what strategy you used for generating the enum. Did you do this manually, or using some script? What strategy do you have for keeping it up to date with new releases of tzdata?

Cheers,
Tobias

> On 12 Feb 2018, at 13:59 , Goudge, Stephen <stephen.goudge at petards.com> wrote:
> 
>> -----Original Message-----
>> From: tz [mailto:tz-bounces at iana.org] On Behalf Of Tobias Lindaaker
>> Sent: 09 February 2018 12:44
>> 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.
>> 
>> <snip>
>> 
>> 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.
> 
> Back in 2008 I posted here that I am doing pretty much exactly the same thing as requested here: basically, I have a C enum that lists out all the zones and as new ones are created this gets extended. A simple table, indexed on that enum, converts to the string name, such as "America/New_York". This has to be manually updated as new names are added. This is (still) being used to allow timestamps to be stored in UTC but tagged with their origin zone - in a space-efficient fashion for an embedded system - so that we can display UTC or the correct local time in a user interface.
> 
> Original post: https://mm.icann.org/pipermail/tz/2008-January/014801.html
> 
> As there was zero interest shown in this at the time, I've still not yet bothered to clean it up, get a GitHub account and post it, but I'm quite willing to do so if there is any interest these days (though the amount of clean-up done will start at - none!)
> 
> Regards,
> 
> Stephen Goudge
> Senior Software Engineer
> 
> Petards Joyce-Loebl Limited
>   390 Princesway
>   Team Valley
>   Gateshead
>   Tyne & Wear
>   NE11 0TU
> 
>   T   +44 (0) 191 420 3015
>   F   +44 (0) 191 420 3030
>   W  www.petards.com
> 
> ___________________________________________________________________________________________
> 
> This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud
> ___________________________________________________________________________________________
> 
> This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful.
> 
> Petards Group plc is registered in England & Wales. Company No. 2990100
> ___________________________________________________________________________________________