Proposal: API for thread-safe time zone functions

Paul Eggert eggert at twinsun.com
Thu Jun 7 20:29:45 UTC 2001


> Date: Thu, 7 Jun 2001 15:28:20 -0400 (EDT)
> From: Garrett Wollman <wollman at khavrinen.lcs.mit.edu>
> 
> > It seems a bit drastic for my purposes.  Also, timezones feel rather
> > different from locales to me.
> 
> I would agree with this statement.  For example, the timezone
> America/Montreal is appropriate for both en_CA and fr_CA locales,

No, because with TZ='America/Montreal' the 'date' command and the
strftime "%Z" format both output EST/EDT, whereas a French Canadian
would prefer HNE/HAE.  See the Canadian standard CAN/CSA-Z234.4-89.

> and conversely there are a dozen timezones which are all used
> concurrently with the en_CA locale.

Yes, under the POSIX model, the fr_CA locale does not specify the
spelling of time zone abbreviations; all it does (as of POSIX
1003.1-200x draft 6) is place certain constraints on the
abbreviations.

However, we're not talking only about the POSIX model here: we're also
talking about the Olson extension to the POSIX model, and we should
design an interface that works well for it, too.

One of the things about the Olson model is that it's easier to use for
English-speakers: you just say TZ='America/Montreal' instead of having
to say something like TZ='EST5EDT,M4.1.0,M10.5.0'.  Unfortunately,
though, the Olson extension currently doesn't work well for French
Canadians who want HNE/HAE.  They have to fall back on a POSIX setting
like TZ='HNE5HAE,M4.1.0,M10.5.0'.  But this mishandles timestamps
before 1987, and also it's a confusing interface that is hard to get
right.

I think a French Canadian should get HNE/HAE by setting
TZ='America/Montreal' and LC_TIME='fr_CA'.  This doesn't happen now,
but POSIX allows this behavior, and (from a user's point of view) it
is quite desirable.  This is on my list of things to add to the Olson
extension.

Hence there ought to be an interaction between time zones and locales
of some sort, and any thread-safe strftime replacement should be able
to access a thread-local time zone and locale information, e.g. by
having one or two extra arguments.



More information about the tz mailing list