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