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@munnari.OZ.AU> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Clive D.W. Feather" <clive@demon.net>; "Peter Ilieve" <peter@aldie.co.uk>; <tz@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@jtcsv.com> Message-ID: <005301c56a2f$ca8a36f0$6501a8c0@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