[LEAPSECS] Multi-timezone meetings

[Tony Finch]

Rob Seaman <seaman at noao.edu> wrote:

>

> > The way to deal with multi-location metings is to choose a primary

> > location, then it it obvious what will happen when TZ rules change.

>

> Interesting.  Immediately after that I said:

>

> >> Whatever our individual positions on the issues, they will be better

> >> served by collecting complete and accurate use cases and engineering

> >> requirements.



> I was describing aspects of the problem space and neither discussed, nor

> asked advice on, the various solutions we may have implemented.


That's fine, but if someone mentions a problem as if it has not yet been
solved then it's rather tempting to state the solution. However if you
really insist on discussing situations I can explain how they are handled.

There is a slight similarity between time and calendaring in that bad
standards (UTC and iCalendar) are hindering the deployment of correct
systems. UTC is bad because it is incompatible with ancient notation and
it is unpredictable; the correct solution is to use either TAI or UT1 as
appropriate. I explain some of iCalendar's failings below, and in more
detail at http://fanf.livejournal.com/104586.html


> 	1) The conference rooms have multiple clocks on the walls for each

> major location.  Attempts to deploy clocks that automatically adjust to

> DST changes have failed [...]


Displaying the time correctly for multiple locations has been solved for
decades. If clock manufacturers are too lame, try attaching a large
display screen to a unix box running an international clock app, and keep
the TZ data up-to-date.


> 	2) 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.


Actually scheduling software is broken because it cannot cope with DST
rule changes nor timezone boundary changes.

The problem is that appointments are stored as an absolute UTC timestamp
or an equivalent form such as local time plus offset. If the TZ changes
then the stored time of the appointment becomes incorrect. Fixing these
broken appointments is enormously painful - see for example
http://support.microsoft.com/?kbid=930879

If you store appointments as local time and place, then there is no need
to do any fixing of appointments: you just update the TZ rules.

The calendaring people are "fixing" this problem by switching to a model
where times are stored as a local time and associated time zone. At the
moment the associated time zone is represented as a copy of the TZ rules,
which is just a very bulky way of giving the offset. (Though to be fair
this format is an improvement for repeating events.) There is a project of
the Unicode Common Locale Data Repository to develop a set of standard TZ
names which will in due course be used to refer to an appointment's
associated time zone by name.

However that still doesn't work. Say, for instance, your business has two
offices, one in London and one in Edinburgh, and your calendaring system
has thousands of appointments in each place, all associated with the
British time zone. Then the Lighter Later campaign succeeds to switch
England to CET/CEST but Scotland decides to stay on WET/WEST. The British
time zone needs to be split and at least half of the appointments need to
be rewritten to accommodate the change.

If you store appointments as local time and place, then there is no need
to do any fixing of appointments: you just update the association between
place and zone.

(Perhaps a better example is Indiana which has had a very large number of
TZ boundary changes.)

The issue of making users aware of what happens to the meeting schedule
around DST transitions is fairly easy to handle: each scheduled event
includes all the relevant secondary locations, so that the user interface
can display the event in the current best estimate of the local time for
all the attendees. The app probably knows the user's current location so
it can highlight the appropriate one.


> 	3) There rarely is a "primary location".  Attempting to assert one

> would have political ramifications.


The primary location is only primary for convenience, so it'll be the
location of the organizer or the largest group of people. If neither of
those is politically acceptable you can choose any other location or even
a virtual location such as UTC. But if you do that (a) you need to get
over yourself, and (b) you are setting yourself up for greater
rescheduling pain when TZ changes occur.


> 	4) Most meetings involve three or more timezones.  Certain hours

> of the day are highly desirable because they are convenient for most or

> all sites.  Others are highly undesirable due to conflicts with local

> lunchtimes, etc.


This is also made easier to handle by attaching the secondary locations to
the appointment so that all the times are obvious to the organizer.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Dover, Wight, Portland, Plymouth, North Biscay: Westerly or southwesterly, 4
or 5, increasing 6 or 7 at times. Slight or moderate, becoming rough or very
rough in west Portland and Plymouth. Occasional rain. Moderate or good.