Proposal: API for thread-safe time zone functions

Garrett Wollman wollman at
Thu Jun 7 22:09:31 UTC 2001

<<On Thu, 7 Jun 2001 13:29:45 -0700 (PDT), Paul Eggert <eggert at> said:

> 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.

The abbreviation is localized, but the timezone itself (in the
specialized sense we use here) is locale-independent.

> I think a French Canadian should get HNE/HAE by setting
> TZ='America/Montreal' and LC_TIME='fr_CA'.

I think we are in violent agreement.

> 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.

>From a maintenance perspective, I don't think that localized
abbreviations are properly part of the timezone, but rather part of
the LC_TIME locale information used by strftime().  My reason is that
most of the timezone abbreviations are unlikely to be localized; each
locale will have a set of timezones which are relevant to the culture
of the locale, and which will be localized, but the vast majority of
the timezone database would not be localized in most locales.


More information about the tz mailing list