Rob Seaman <sea...@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 <d...@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. _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
