[LEAPSECS] Multi-timezone meetings

[Tony Finch]

Rob Seaman <seaman at noao.edu> wrote:


> In an earlier message I also said:

>

> > Scheduling software does a pretty good job of supporting the range of

> > timezones and DST rules (presumably layered on Olson), except for

> > educating the users who often forget during changeover that Arizona

> > and Hawaii, in particular for our community, don't observe DST.

>

> A typical exchange from my mailbox:

>

> > Subject: Re: Telecon tomorrow

> > Date: November 15, 2011 9:57:54 AM MST

> >

> > Yes, 10:00 PST - that's what happens when you just cut-and-paste old

> > messages!  -- M.

> >

> > On Nov 15, 2011, at 8:47 AM, Rob Seaman wrote:

> >

> >> I believe you actually mean Pacific Standard Time, not PDT.  See you

> >> at 18:00 UTC 15 Nov 2011?

> >>

> >> On Nov 14, 2011, at 12:46 PM, M. wrote:

> >>

> >>> We will have our regular telecon tomorrow morning at 10:00 PDT...

>

> Which is to say that this email exchange was part of the solution

> actually implemented.


The problem here is that you have tools that are either incorrect or too
inconvenient to use. Microsoft Exchange is an example of an incorrect
tool: it has a habit of referring to British Summer Time as GMT, which
leads to people being an hour late.

Time zone names are hard because there are so many of them and they
need translating into all the foreign languages you support. Abbreviated
names are not unique and there is often no standard abbreviation for a
zone.

There are a couple of ways to avoid this tar pit in most situations: just
display local time and place, and leave the time zone implicit; or add the
currently predicted numeric TZ offset which reassures geeks but can be
unfriendly to the innumerate. However you still have the problem of the
user interface for associating places with time zones which gets you back
into the naming tar pit.

Note that all of this is discussing user interface matters. Once you have
the right data model then user interface questions are not unnecessarily
hard to answer since you don't have to work around mismatches between the
model and reality. For instance, if you tie an event to a timezone too
early then you have to display the TZ information since it is no longer
redundant and may be incorrect.


> Like 80-90% of the world Arizona does not observe DST, so the "regular"

> time for the telecom changed for me by an hour.  A local meeting had to

> be rescheduled as a result.  If such a meeting included South American

> partners it might have changed by two hours as the North went off DST

> and the South went on.  At issue isn't each meeting alone, but the whole

> set of standing and one-time meetings that have to be revisited at least

> twice a year.


These are inherent difficulties and the best you can do is to make it
easier to handle the rescheduling. If the tool knows all the places
covered by a regular meeting then it can warn you when the regular time
is going to change for some participants, and not warn you about meetings
whose time changes in step for all participants.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Variable 3 or 4, becoming north or northeast 5 to 7. Slight
becoming moderate or rough. Rain or thundery showers. Moderate or good.