RLAW at nc.rr.com
Sun Jun 5 00:33:12 UTC 2005
> Here is the problem. You fill in a calendar form for a recurring meeting,
> one that is to happen at "10:00 am GMT". If (a) the software maps the
> to the tzid Europe/London, then the time of that meeting will be 10:00Z in
> the winter, and change to 09:00Z in the summer. If (b) the software maps
> "GMT" to Etc/GMT, then that meeting will be at 10:00Z all year round. It
> can't do both, and doing (a) would cause all kinds of other problems.
> If you (or others) have any ideas for handling this, I'd be glad to
I used to work for a company that provided a logistics information system.
We exchanged electronic messages with all sorts of enterprises worldwide.
The rule for chronological data was basically, if you want to communicate a
date/time to us, you must send it either as UTC (or local time with UTC
offset specified), or as a local time along with the name of the place where
the event occurred. (As an aside, I must mention that the place name had to
be validated. If you sent the name "Springfield, U.S.A.", it would be
rejected for ambiguity.) We used the tz database, with other supporting
data, to convert between local time and UTC at each location. The results
were generally acceptable.
If that solution can't be adapted for your situation, then maybe you'll need
to do some user education. Users tend to assume that what works for them
will work for everyone. For example, users in New York want to say "Eastern
Time" and let the computer do everything else. They don't care that users
in Indianapolis also want to say "Eastern Time", but diverge from New York
in the summer (until 2006, anyway). Users in Toronto who specify "Eastern
Time" are in synch with New York for the present, but there may have been
times in the past, or come times in the future, when the DST/standard time
switch is on different dates in Canada and the U.S. Users in Sydney may
also want to say "Eastern Time", but it means something totally different.
One possible way of dealing with the ambiguity is to let users specify
"Eastern Time", but then pop up a disambiguation window that explains the
difference among the various meanings of that phrase, and asks them to pick
the right one.
Obviously it would get annoying to see that window pop up all the time.
There could be mitigating work-arounds. One possibility is to let the user
pick a default time zone for that computer or application. Another is to
provide unique, unambiguous time zone names like "Eastern Time - New York",
"Eastern Time - Indianapolis", etc. as alternatives to the ambiguous names.
-- Gwillim Law
More information about the tz