[tz] tzdb timezone names/identifiers and links
Brian.Inglis at SystematicSw.ab.ca
Thu Feb 28 18:53:57 UTC 2019
On 2019-02-26 11:17, Tony Finch wrote:
> Guy Harris wrote:
>> And I'm not even convinced that users want to care about tzdb regions;
>> those regions don't completely correspond to, for example, what people call
>> "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't
>> correspond to the America/Denver tzdb region - Arizona is in the "Mountain"
>> time zone, but it hasn't done standard/summar time switching since 1968,
>> unlike other parts of that time zone.
>> What I suspect users want is to have clock time work appropriately for
>> their location; if doing so doesn't involve knowing or caring about the
>> details of the tzdb, so much the better.
> Up to a point... A common cause of significant confusion is when people are
> trying to organize meetings between people in multiple time zones. I think
> the confusion is due to poor calendaring data models which make it difficult
> to provide a user interface that illustrates what is going on. (old long
> version of these thoughts: https://fanf.livejournal.com/104586.html) The key
> point is to attach one or more locations to an event. The system needs to be
> able to look up which timezone applies to which locations; there are ways to
> make that easyq. One of the locations is the primary location, and the
> event's scheduled time is local time at that location; the secondary
> locations allow users to easily see what time it is for all the participants,
> so they don't accidentally schedule something for 05:00. And it allows the
> system to automatically flag up weirdnesses that happen in March or October
> or when TZs change. In particular it's easy to find out when TZ changes have
> effects that matter to meeting schedules without false positives. And if the
> primary UI is location, not TZ, there's less likelihood of idiocies like
> Microsoft Exchange saying the time in Cambridge in July is GMT.
With conference calls, often an organizer will be unaware of parties' locations,
so client confirmations need to feed back locations which the organizer's client
can record as supplementary locations with associated supplementary time zones.
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
More information about the tz