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. For example, suppose I am on a business trip in Sydney using a program that is, accepting a calendar invitation from an American in New York, with tzid America/New York and the date 2005-01-12T18:00:00, and my locale is set to en_US, and my timezone is set to Austrialia/Sydney. In many calendar programs you can see the datetime in both your timezone and the originators. Assuming that we make no other changes*, if if the program chose to use a format that showed the timezone abbreviation, and you have set your locale to en_US, then you would see "January 12, 2005 10:00 EST" for the originator's zone. * 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 ...
Mark ----- Original Message ----- From: "Ken Pizzini" <tz.@explicate.org> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Monday, June 06, 2005 18:24 Subject: Re: Timezone translations
On Mon, Jun 06, 2005 at 05:31:16PM -0700, Mark Davis wrote:
What we couldn't have is two conflicting values in the same locale, such as:
en_US: America/New York <=> EST Australia/Sydney <=> EST ... 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.
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?
--Ken Pizzini