[tz] EST/EDT vs AEST/AEDT in AQ

Guy Harris guy at alum.mit.edu
Tue Apr 16 03:51:06 UTC 2013


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