[tz] Time zone renaming overview

Tim Thornton tt at smartcomsoftware.com
Tue Apr 16 07:14:48 UTC 2013


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.
This may be by a number of possible criteria, to name a few:
- what is specified by the laws governing that area
- what is in common place usage by the inhabitants of that area
- creation of a unique and consistent time zone nomenclature, removing the
inconsistencies of the above two methods
- an arbitrary abbreviation for internal use by the TZ code and data that
may approximate the above

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.

Unless we do this first, changes are likely to be made on the basis of who
shouts loudest, 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.

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. 

Tim

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

www.smartcomsoftware.com

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


-----Original Message-----
From: tz-bounces at iana.org [mailto:tz-bounces at iana.org] On Behalf Of Guy
Harris
Sent: 16 April 2013 04:51
To: tz at iana.org list
Subject: Re: [tz] EST/EDT vs AEST/AEDT in AQ


On Apr 15, 2013, at 6:47 PM, Tobias Conradi <mail.2012 at tobiasconradi.com>
wrote:

> On Tue, Apr 16, 2013 at 2:58 AM, Guy Harris <guy at alum.mit.edu> wrote:
>> 
>> On Apr 15, 2013, at 7:59 AM, Tobias Conradi <mail.2012 at tobiasconradi.com>
wrote:
>>> On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive at davros.org>
wrote:
>>>> What we actually want to know is what Lord Howians actually use.
>>> Why? Me not. Localization is out of scope of the database. This belongs
to CLDR.
>> 
>> Another way to think about this is to say
>> 
>>        The abbreviations supplied by the tz database are the
abbreviations appropriate for the C locale.
> 
> I guess "C locale" is not restricted Lord Howe English.

Well, according to International Standard ISO/IEC 9899, second edition
1999-12-01 (a/k/a "C99"), section 7.23.3.5 "The strftime function",
paragraph 7:

	In the "C" locale, the E and O modifiers are ignored and the
replacement strings for the following specifiers are:

		%a the first three characters of %A.
		%A one of ''Sunday'', ''Monday'', ... , ''Saturday''.
		%b the first three characters of %B.
		%B one of ''January'', ''February'', ... , ''December''. %c
equivalent to ''%a %b %e %T %Y''.
		%p one of ''AM'' or ''PM''.
		%r equivalent to ''%I:%M:%S %p''.
		%x equivalent to ''%m/%d/%y''.
		%X equivalent to %T.
		%Z implementation-defined.

so it's up to the implementation what to do for time zone names.  I don't
know whether C11 has specified more there.

Annoyingly, the latest version of the Single UNIX Specification says:

	The tzset() function shall use the value of the environment variable
TZ to set time conversion information used by ctime, localtime, mktime, and
strftime. If TZ is absent from the environment, implementation-defined
default timezone information shall be used.

	The tzset() function shall set the external variable tzname as
follows:

	tzname[0] = "std";
	tzname[1] = "dst";

	where std and dst are as described in XBD Environment Variables.

which doesn't speak of LANG or LC_TIME.  I *think* the idea is that if TZ is
set to a POSIX-style string, the zone abbreviations are as specified in that
string.  If it's not (which, in theory, mean it should begin with a :, e.g.
:America/Los_Angeles, although anything with tzcode-derived code will also
interpret anything non-POSIX but *not* beginning with a : as a zone name as
well), presumably the "implementation-dependent" in XBD "Environment
Variables":

	The value of TZ has one of the two forms (spaces inserted for
clarity):

		:characters
	or:

		std offset dst offset, rule

	If TZ is of the first format (that is, if the first character is a
<colon>), the characters following the <colon> are handled in an
implementation-defined manner.

means it presumably could honor LANG or LC_TIME, i.e. the locale setting.

So what time zone abbreviations you get in the C locale, if an
Olson-database setting of TZ is used rather than a POSIX setting, doesn't
appear to be specified by any current standard.  (Is there even anything
there requiring that the abbreviations be 3 characters or longer?  The
description of %Z seems to indicate that it could expand to a time zone name
(Windows-style?):

	Z	Replaced by the timezone name or abbreviation, or by no
bytes if no timezone information exists.

or expand to nothing at all if you don't have time zone information.

> It would be convenient if strftime would return MEZ instead of CET.

Presumably meaning "in locales such as de_DE".  In
"en_{GB,AU,NZ,CA,US,etc.}", it would presumably return CET.

> This might be even more important for non-Latin script writing systems.

The CLDR entries for China have what appear to be Chinese
names/abbreviations, in Hanzi, for time zones.





More information about the tz mailing list