Timezone translations

[Mark Davis]

> But "EST" is ambiguous, how can you possibly use it for your purposes?

As I tried to say, we *can* have different translations for different
locales. So we could have:

en_US:
 America/New York <=> EST

en_AU:
 Australia/Sydney <=> EST

en:         (the default English locale, with unspecified country)
 Europe/Tallinn <=> EST

What we couldn't have is two conflicting values in the same locale, such as:

en_US:
America/New York <=> EST
Australia/Sydney <=> EST

>Similarly, a meeting at 4pm every Monday
is at 4pm standard time in winter, and 4pm summer time in summer, whether
the meeting schedule was set in summer or winter.

That is clearly true. And that's what we mean by 'generic' (or wall time).
And if everyone in the meeting shares the same implicit timezone and thus
references that particular wall time, that is not an issue. Or even if we
are setting up a recurring telecon meeting with people from many different
timezones, as long as I can communicate that I want wall time according to
tzid X. The whole issue is around how to identify the tzids that are being
used, in this scenario and others.

>Second, the only half way reliable way to work out what time zone applies
is to find out what location the time is supposed to apply in, that is,
if someone wants to schedule a meeting at 4pm, you need to know 4pm in
which city.
...
>Even as just friendly info, zone names help rather than hinder only in
those locations (countries really, though Europe might count as a country
for this) where there are multiple timezones - in others, the time is just
the time, and has no name at all.

Also understood. As I'm sure you know, we cannot assume that the user's
locale determines the timezone. I could have en_US as my locale, but that
doesn't tell me the timezone; I might actually be working in Paris for a
while. One of our tasks is to provide data to allow users -- of any
language -- to pick timezones. For that we need to be able to show a list,
where a user can pick the timezone from any of the world's timezones, and
the list should be localized to be what makes sense in that user's locale.
In that list, we need the names to be unique; having two different tzids
with the same name, and without any other qualification would not let the
user make a choice.

For this generic name, what we have in CLDR is provision -- for any given
locale -- for either showing a translation of the country (+city if the
country alone is not sufficient), or for having an explicit override to some
other customary form. Now, it may well be, that there is no customary name
for "British Time". In that case, the correct action on our part may be to
simply delete the override, and fall back to the default, which I think
would be "United Kingdom (London)"

A second task is formatting/parsing a string with a date and or time,
including the zone. For that, as I mentioned earlier, we have in the past
provided several options. Thus given a locale we could format/parse "10:13
PST" or "10:13 PDT".

Currently we require that all of the labels -- if supplied -- also be
unique, but as I said in my message of Sunday, June 05, 2005 17:23 (my
time), one thing I can bring up for the CLDR committee to decide is whether
we should relax that requirement, so that for a given locale we could allow
name collisions -- where it doesn't matter which tzid is generated. That is
predicated on the fact that if I parse "10:13 GMT", it doesn't matter
whether GMT maps to Etc/GMT or whether it maps to Europe/London; I get the
same results.

‎Mark

----- Original Message ----- 
From: "Robert Elz" <kre at munnari.OZ.AU>
To: "Mark Davis" <mark.davis at jtcsv.com>
Cc: "Clive D.W. Feather" <clive at demon.net>; "Peter Ilieve"
<peter at aldie.co.uk>; <tz at lecserver.nci.nih.gov>
Sent: Sunday, June 05, 2005 19:57
Subject: Re: Timezone translations


    Date:        Sun, 5 Jun 2005 17:36:33 -0700
    From:        "Mark Davis" <mark.davis at jtcsv.com>
    Message-ID:  <005301c56a2f$ca8a36f0$6501a8c0 at sanjose.ibm.com>

  | > Are you also going to declare that New York can't use EST?
  | No. I don't see how what I said would give you that impression.

But "EST" is ambiguous, how can you possibly use it for your purposes?

Aside from the (several) different meanings in north America, it's also
the name of (both) the summer and standard timezones in eastern
Australia (all 4 (or is it more) different versions of them).

The first thing that you should note is that you do not need to distinguish
(in user input) the difference between summer and standard timezones,
you can always work that out from the date, assuming you know the locality.

People use either "local time" (either the local time where they are,
which is most common, or sometimes "local time at location X"), or they
use UTC (whether they call it that or GMT).   No-one expresses the time
in terms of what it would be if only it was not summer right now, or if
summer time didn't apply.    Similarly, a meeting at 4pm every Monday
is at 4pm standard time in winter, and 4pm summer time in summer, whether
the meeting schedule was set in summer or winter.

Second, the only half way reliable way to work out what time zone applies
is to find out what location the time is supposed to apply in, that is,
if someone wants to schedule a meeting at 4pm, you need to know 4pm in
which city.    Given that there's no longer any ambiguity at all, and just
a combination of programming, and database, to convert to universal time
so it can be shared with others (and represented in whatever timezone is
convenient for them, which should either be in numeric form (+1000, -0700,
or something) or in terms of a location.

Asking for any form of time zone name input is just asking for trouble.
Outputting one where you intend its use to be anything more than a
comfort blanket for the user is just plain silly.

Even as just friendly info, zone names help rather than hinder only in
those locations (countries really, though Europe might count as a country
for this) where there are multiple timezones - in others, the time is just
the time, and has no name at all.

kre