Timezone translations

[Robert Elz]

    Date:        Mon, 6 Jun 2005 17:31:16 -0700
    From:        "Mark Davis" <mark.davis at jtcsv.com>
    Message-ID:  <020e01c56af8$37c072c0$6501a8c0 at 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