This is something that I have not seen any calendar software do right. I agree with the argument that time zones for future events should be strings, not numbers. OK so you might need to do a lookup to disambiguate, but that is because there is a possibility of change. I once had a MrCoffee machine which would not make coffee unless the time was set and would lose the time setting with the least provocation from the mains supply. When I used Outlook, it never had the (obvious to me) feature of being able to specify the local time for a meeting. I used to have recurring conference calls. Some were based on US time, others on European time. It is a pretty obvious fact to me that this will cause the meetings to sometimes recur at different times and this would depend on the time zone for the meeting, not the time zone my laptop happened to be in at a particular time. Equally, I never found a system that was clever enough to work out that if I take a trip to another time zone, that this should affect the default meeting times for all the meetings scheduled within the trip. I would have imagined that it was a no-brainer for airlines and travel agencies to work out that they need to take account of local time correctly. But no, I had an application that was meant to stuff flight data into my calendar, it invariably did this wrong. Flights from BOS to SFO would be scheduled for 3 hours duration, flights from SFO to BOS would be scheduled for 9 hours duration. People have told me that there are 'hidden problems' in developing a calendaring spec. If implementations as widely used as Outlook are unable to manage the obvious problems of simple business trip, I hate to think what the 'hidden problems might be. 2010/3/18 Tony Finch <dot@xxxxxxxx>: > On Thu, 18 Mar 2010, Patrik Fältström wrote: >> >> We should from IETF point of view review the ical spec, and try to push >> timezone information away from the objects, and to a central repository. >> The timezone offset should be calculated based on the geographical >> location of the event. > > Yes. http://fanf.livejournal.com/104586.html > >> I.e. if I (or my application) know something happened at 13:32 on >> 2010-01-02 in Stockholm, that is I claim the best way of stating when >> something happened. Even better example is 13:32 at 2123-01-02 in >> Stockholm, as the chance Stockholm still exists in 2123 is higher than >> Stockholm use the same daylight savings rule then compared with today. > > Yes, though you need a disambiguation flag for times when the clocks go > back. > > In general RFC 3339 (i.e. date + time + UTC offset) is right for recording > timestamps of events that have occurred, but wrong for scheduling human > events in the future. > > Tony. > -- > f.anthony.n.finch <dot@xxxxxxxx> http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf