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@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Guy Harris Sent: 16 April 2013 04:51 To: tz@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@tobiasconradi.com> wrote:
On Tue, Apr 16, 2013 at 2:58 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Apr 15, 2013, at 7:59 AM, Tobias Conradi <mail.2012@tobiasconradi.com>
wrote:
On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive@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.