[tz] Rules for TZ+ database

[Russ Allbery]

random832 at 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 at stanford.edu)             <http://www.eyrie.org/~eagle/>