Timezone translations

[Ken Pizzini]

On Mon, Jun 06, 2005 at 07:06:48PM -0700, Mark Davis wrote:
> > How are things supposed to be handled if you are using en_US
> > for your locale, and you are working in Sydney for a while?
> 
> I'm not quite sure what kind of scenario you are thinking of, so I'm not
> sure how to answer.

What I was attempting to get at, is that I'm completely failing to
see why it would be okay to have ambiguity inter-locale, yet have
it be a problem intra-locale.  If EST has to be unique within en_US,
then when a New Yorker travels to Sydney there is an ambiguity just
as big as if EST were allowed to have multiple meanings in en_US in
the first place.  If the ambiguity can be resolved in one situation,
then it should be able to be resolved in both (as far as I can see).

In the example you gave, the answer seemed to be, in essence,
"in TZ=America/New_York, EST means UTC -0800, and in TZ=America/Sydney,
EST in the austral summer means UTC +1100, and data interchange is
always normalized to UTC or UTC with offset", which seems like
a perfectly reasonable solution to me, and is completely independent
of what locale is in effect, and means that en_US should be able to
handle many meanings for EST, with the TZ associated with a given
timestamp resolving which EST is meant.


> * As I said below in that message;
> >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
> ...

Okay then, as of yesterday you've conceded doubt about CLDR's current
stance on the topic.  I think there is still room for discussion
about how best to drive home to the CLDR folk that any uniqueness
requirement in this realm is a bad idea.  Official zone names and
abbreviations are what they are, and I doubt there'd be any luck in
trying to convince the various governments and societies involved
to adopt a globally rational system.  (TZIDs, however, can be
expected to be unique, as that is the whole reason that these
otherwise non-standard and somewhat ad-hoc identifiers were created.)

And to make sure I'm clear on the point, I'll emphasize: non-uniqueness
applies to "long form" names as well as the short abbreviations ---
scheduling something at "14:45 Eastern Standard Time" is almost as
meaningless as scheduling it for "14:45 EST".  (I.e., is that Eastern
Australia, Eastern United States, or Eastern Canada?  The last two are
currently equivalent, but there is no reason to expect that they always
will be; there have been times in the past where at least the transition
rules were different.)  The nature of the ambiguity is the same, and the
need to resolve the ambiguity by means outside of the locale
definitions are just as necessary.

		--Ken Pizzini