random832@fastmail.us writes:
If someone schedules a meeting at (e.g.) noon next January, and between now and then the state that meeting takes place in switches from (e.g.) Eastern to Central time, then the program _must not_ move the meeting to eleven. Which means blindly storing the UTC or blindly storing a time+offset is inappropriate.
The obvious common case for this problem is scheduling a recurring meeting at noon in a zone that does a daylight saving switch. Storing the recurring meeting time only in UTC or in zone+offset will obviously not work, since the meeting should not be moving by an hour from the perspective of local time when daylight saving switches happen. I suspect what most people do, and what I've always seen done, is that meeting times are stored as time plus zone identifier and then actual times are recalculated either on display or periodically based on the current rules for that zone identifier. As Guy points out, this still doesn't help if the zone is split or if the locality moves to a different zone, but I've not seen anyone make a serious attempt to handle that case. I think in most places it's rare enough that software isn't written to cope and a human just has to go edit the meetings and fix them. Airlines may have different rules since accuracy in multiple localities and coordination of times across multiple localities is more critical to them than for most meeting and calendaring applications. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>