Poul-Henning Kamp <[email protected]> wrote: > In message <[email protected]>, "Daniel R. Tobias" > writes: > > >When I'm making an advance dinner reservation for 7 PM on October 1, > >2014 in New York City, I expect that [...] > > That used to be the "sensible party position", but it breaks down > in heaps once you start to schedule tele-conferences etc.
In theory it works fine, if it is done properly. The organiser needs to pick a primary location, where the local time of the appointment remains fixed. There might be some secondary locations if some participants are elsewhere; these are useful for automatically displaying the correct time of the appointment for each person, and for the organiser to spot if their proposed time happens to be 04:00 for one of the participants. The secodary locations are also useful when a TZ rule change occurs: the scheduler can find all the appointments that are affected by the rule change, that is, appointments that occur in multiple locations where the TZ rule change affects the locations differently. This kind of automated assistance is impossible if you schedule in UTC. If you schedule in a fixed zone (whether fixed UTC offset, or fixed local time rules, or fixed Olson tz name) there are situations where a rule change will invalidate your scheduling. However current scheduling software requires you to schedule in this broken way because the main calendaring data format (iCalendar) has the wrong data model. So in practice it is impossible to schedule things in a way that is robust against TZ changes. There are other problems with existing calendaring software such as getting time zone names wrong, e.g. implying the time zone in Lisbon in the summer is called GMT. So in practice scheduling in UTC makes sense. Longer version of this argument: http://fanf.livejournal.com/104586.html Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
