Time Zone Localizations

jcowan at reutershealth.com jcowan at reutershealth.com
Fri Jun 11 20:23:20 UTC 2004

Mark Davis scripsit:

> However, to reduce the translation requirements and make the data
> more manageable, we do want to set up some uniqueness criteria. If
> two IDs have exactly the same behavior since the time when time zones
> were adopted,

In fact the Olson data do not separate timezones in a given country
that have been the same since 1970-01-01.  Otherwise, Indiana would have
something like 30 time zones instead of just four.

> and have always been in the same country over that period, we only want
> one of them to be in the main list. The other can be an alternate --
> and still work-- but we would recommend an extremely low priority
> on translation.

I think that is a mistake, for two reasons:  national chauvinism and
future-proofing.  About the former, nothing need be said; but the whole
point of setting your zone to the country you are in (especially if you
live there) is that you don't want to have to reset it if your national
legislature changes the rules, either the DST rules or the zone proper.
Within the EU, DST rules are harmonized, but which zone to adopt is a
purely national decision.

> Many (I would dare say the vast majority) of end users just don't care
> now that there was once a difference between Dawson, Whitehorse and
> Los Angeles.

This strikes me as backwards.  If you're in the U.S., you should see U.S.
choices; in Canada you should see Canadian ones.

> Absolutely!

I think the series of fallbacks is unnecessarily complex.  In particular,
the fallback from "Pacific Time" to "GMT-07:00/08:00" doesn't tell me
that much, because I don't know a priori whether it's winter or summer

In addition, it fails to exploit the nice thing about the use of city
names in Olson, namely that city names don't need that much localization:
in the vast majority of cases, the internationally known name is the
only name.  (Transliteration might be required if the current locale
has no Latin letters.)  Thus the full combinatorial explosion of city
name x language can mostly be short-circuited.

I propose a simpler scheme, therefore:

1) If you have a translation for the time zone name x the language, use it.

2a) Get the localized name for the city (or if none, the Olson city name);
2b) Get the "Tampo de '%1'" schema for the language (or if none, use just "%1");
2c) Substitute the city name into the schema and use that.

When I'm communicating with users about the Reuters Health system, I always
refer to events occurring at such-and-such a time, New York time.  That
communicates not only a GMT offset but a set of DST rules.  This is also
what's typically done in legal documents -- see the legal ads for bond
redemption announcements in a newspaper.

John Cowan <jcowan at reutershealth.com>     http://www.reutershealth.com
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, LOTR:FOTR

More information about the tz mailing list