Date: Mon, 6 Jun 2005 17:31:16 -0700 From: "Mark Davis" <mark.davis@jtcsv.com> Message-ID: <020e01c56af8$37c072c0$6501a8c0@sanjose.ibm.com> | 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. Of course. The question is how you should disambiguate when the precondition is not true. | 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. No, that is exactly what you should not attempt to do. It just doesn't work, it isn't human friendly, and you get to suffer interminable lectures from the people on this list. | The whole issue is around how to identify the tzids that are being | used, in this scenario and others. Yes, and the way to avoid it is to just not attempt to do it. Your later comments make it clear that you misinterpreted my suggestion from my earlier message, so this time I will attempt to be clearer. (And any blame for misinterpretation is mine, lots of people manage to fail to understand me, so the fault is obviously mine). | Also understood. As I'm sure you know, we cannot assume that the user's | locale determines the timezone. No. I didn't mean that kind of locale (as in the posix type magic word "locale"). I meant it as in the form you'd find it in the dictionary (normal English dictionary, no specific technical terms). That is, a rough synonym for "location". I am not suggesting that you attempt to automate, or guess, the particular local time to apply, I'm suggesting that you ask the user "in which city does that local time apply". That is, the user can say "we will have this meeting every week, at 4pm, Paris (France) time." Then you have no more ambiguity at all (or not unless the French government goes absurdly even unimaginably, wild with its time definitions). It makes no difference for this what the user's Posix Locale is (except perhaps how "Paris" and "France" might be spelled), nor where the user happens to be geographically or network topologically located when the meeting time is set (though one of those may be used to suggest a default local time to apply). Just give up on using any kind of timezone name for any algorithmic purpose (when appropriate, they can sometimes, but only sometimes, be used in user presentation). I know this is hard to accept for Americans, who are used to dealing with times being specified as "4pm Pacific", or "7pm Eastern" (etc), and the common frequent use of names for the timezones, rather than specifying them as "the time in Los Angeles" or "the time in New York City" - and for humans, usually, it works just fine - as people just know when you say "Eastern" you mean the time in New York, or Washington, or whatever, and not the time in some bizarre county in Indiana. But most of the world doesn't work like that, time zone names are much less used (even in Australia - in the US, a TV network would advertise a live event as being at some time Eastern, or some other time Pacific, in Australia it would be advertised as some time (Eastern, aka Sydney, being mostly assumed in Australia...) or at some other time in Perth (or sometimes, in Western Australia). "Western Standard/Summer Time", or even just "Western" just doesn't get used. The only name names that you can reliably use are GMT, UTC, and UT, all of which mean +0000 (always) (and they all mean the same thing for any normal human purpose) | A second task is formatting/parsing a string with a date and or time, | including the zone. Forget it. Even given a posix locale you cannot do that. The impossibility of interpreting anything from the abbreviations is why the mail standards now say to use numeric timezones always (even though the old ones are still permitted for backwards compatability) - and why your mail, my mail, and I think everyone else's mail these days, have numeric timezone offsets in the Date: header (and even in Received headers), not alphabetic ones. Just don't even try for this one. kre