[tz] Time zone renaming overview

Tim Thornton tt at smartcomsoftware.com
Tue Apr 16 12:04:20 UTC 2013

I agree that it should be documented for future reference, otherwise we will
just continue having these spats over naming approaches.
You've made it clear that you effectively want a new naming system, which is
one approach, but there are also arguments for aiming to meet legal names
and common usage, even if these are not fully defined. There are also good
arguments for not upsetting the apple cart, and sticking with the existin,
working system.

Smartcom Software Ltd
Portsmouth Technopole
Kingston Crescent
Portsmouth PO2 8FA
United Kingdom


Smartcom Software is a limited company registered in England and Wales,
registered number 05641521.

-----Original Message-----
From: tobias.conradi at gmail.com [mailto:tobias.conradi at gmail.com] On Behalf
Of Tobias Conradi
Sent: 16 April 2013 12:56
To: Tim Thornton
Cc: tz at iana.org
Subject: Re: [tz] Time zone renaming overview

On Tue, Apr 16, 2013 at 9:14 AM, Tim Thornton <tt at smartcomsoftware.com>
> Can I suggest that before we wade in and change time zone 
> abbreviations we ought to step back and agree on what basis the
abbreviations are set.
And documenting this in the Theory file may help in enforcement.

> This may be by a number of possible criteria, to name a few:
> - what is specified by the laws governing that area
Does not work, there can be several esp. in multilingual countries.
It will also involve Romanization for non-Latin script definition in single
language countries, so increasing complexity.

> - what is in common place usage by the inhabitants of that area
Same as above.

> - creation of a unique and consistent time zone nomenclature, removing 
> the inconsistencies of the above two methods
Looks good and the current implementation
- English language as source
- ISO 3166-1 alpha-2 codes as source
- structure in %s
work in that direction

> - an arbitrary abbreviation for internal use by the TZ code and data 
> that may approximate the above
arbitrary and approximation seems to be contradictory to me.

> Also, we need to think through whether changes should be applied 
> retrospectively or not, or whether perhaps we run a new set of 
> abbreviations in parallel to the old ones, which become deprecated as 
> they are replaced by the new ones.
That would require tzcode change.

> Unless we do this first, changes are likely to be made on the basis of 
> who shouts loudest,
or what the TZ Coordinator likes most

> regardless of any merit they may have, and as those promoting changes 
> will each have their own agendas I would expect the naming to become 
> even less consistent than it is.
Depends on how much extra inconsistency the TZ Coordinator lets in.

> I don't use the abbreviations in my use of the database, so apart from 
> having to dig through all of the noise that this debate generates on 
> the mailing list it doesn't affect me much. But perhaps a good 
> starting point would be to review how the time zone abbreviations in 
> this project are currently used, and also what ISO and web standards 
> there may already be for naming of time zones outside of this project, 
> and decide whether we should aim to align with one of them.
On could also approach ISO and ask them to design a standard.

Tobias Conradi
Rheinsberger Str. 18
10115 Berlin


More information about the tz mailing list