2007 change to Daylight Saving Time – v1.1
The purpose of this memo is to discuss the coming change to Daylight Saving Time
in 2007, and the effect upon existing Meeting Maker Calendar customers.
Background
Prior to 2007, in the four major US time zones, Daylight Saving Time began at 2am
on the first Sunday of April (clocks set AHEAD one hour) and ended at 2am on the
last Sunday of October (clocks set BACK one hour). So Daylight Saving Time (DST)
runs from April to October; when DST is not in effect, we are in “Standard” time.
Extended DST
Congress recently passed an Act (HR 6: The Energy Policy Act of 2005) changing
the start and end of DST in 2007 (see section 110). Beginning in 2007, DST will
begin on the second Sunday of March, and end the first Sunday of November.
Although this Act has been signed into law, Congress apparently retains the right to
undo this change pending the results of a study (within 9 months of March 1, 2007)
on its impact. So this is not a “done deal”, but we may not know for sure until 2007!
Note this effectively makes DST start 3-4 weeks earlier (4 weeks earlier in 2007, 3 in
2008) and end exactly one week later. For the purposes of this memo, we refer to
the extra 3-4 weeks in March/April “Gap 1” and the extra week in Oct/Nov “Gap 2”.
Conversion to GMT
In the MM Client, we define each time zone as the offset from Greenwich Mean Time
(GMT). GMT does NOT itself undergo a DST shift. In the US/Eastern time zone,
during Standard time, we are 5 hours behind GMT (GMT -5). During US/Eastern
DST, we are only 4 hours behind GMT (GMT -4). Times are generally stored in the
MM database in GMT. Thus we have routines that convert from any given time zone
to GMT. The “time zone definition” is used for this conversion. This definition
contains the time zone’s basic offset from GMT, plus the DST rule. The DST rule
describes how to determine the date and time of the start and end of DST. It cannot
distinguish between years, so we do not have the ability to simply add in the new rule
for 2007 and beyond. Only a single rule (pre-2007, or 2007 and beyond) can be
expressed.
When converting between two time zones, we convert the date and time from the first
time zone into GMT, and then from GMT into the second time zone.
Issues with not updating
Whatever time zone fixes we implement in a new release the MM Calendar, some of
our customers can’t or won’t upgrade. Here are the problems such customers will
face in 2007. In the following examples, assume all users are running MM 8.5.3.
These items will not be a problem
To create problems in the examples below, we had to specify the following:
• Involvement of both one user whose home time zone is one of the four major
US time zones, and another user who does not use one of those time zones
• A meeting occurring in Gap 1 or 2
Both of these conditions must be in effect for a problem to be seen. Note that if a
meeting includes two users in different major US time zones, they will not see a
problem, as follows:
Example 7: A US/Eastern user creates a single-instance one-hour meeting at noon
sometime in Gap 1 and invites a US/Pacific user (who sees the meeting at 9am
Pacific time). Since both users end up moving their clocks forward on the same day,
they stay in synch with each other and are both on time for the meeting (though, to a
Canada/Ottawa user, they both appear to arrive at 11am for the noon meeting).
Non-US meeting guest is one hour too late to US meeting
Example 1: Suppose a US/Eastern user creates a single-instance one-hour meeting
at noon sometime in Gap 1 (defined above) and invites a guest from the
Canada/Ottawa TZ, which follows the pre-2007 US/Eastern DST rule. Both users will
see the meeting displayed in the Client at noon. However, the US/Eastern meeting
owner has set his clock forward one hour. By the time the Canada/Ottawa guest calls
in (at his noon), it is 1pm in US/Eastern time, and he has missed the meeting.
US meeting guest is one hour too early to non-US meeting
Example 2: The reverse would have happened if the Canada/Ottawa user was the
meeting owner and the US/Eastern user the guest; the US/Eastern user would call in
at noon his time but it would only be 11am in Canada/Ottawa time; he is one hour too
early.
Hidden conflicts for people
Example 3: Continuing example 1 above, suppose the Canada/Ottawa user has
accepted the noon meeting with the US/Eastern user, and also has scheduled his
own one-hour meeting for 11am in his time. The MM Client does not show these
meetings as conflicting, but they are, since the noon US/Eastern meeting will really
occur at 11am Canada/Ottawa time.
Example 4: The US/Eastern user can also have a hidden conflict if he has a 1pm
meeting and has also accepted a proposal from a Canada/Ottawa meeting owner for
a noon Canada/Ottawa meeting (which will occur at 1pm US/Eastern time)
Double-booking for resources
Example 5: Similarly, if there exists a resource that can be used remotely (e.g. a
teleconferencing line), it can be double booked without anyone noticing – e.g. with an
11am Canada/Ottawa reservation and a noon US/Eastern reservation, during Gap 1.
Note that for all of the above examples, the same problems exist during Gap 2,
because the Canada/Ottawa user has set his clock back one hour and the
US/Eastern use has not.
What about recurring meetings
Instances of a recurring meeting that fall into Gaps 1 or 2 will have the above
problems. Instances that fall outside of those dates will not have any problems.
What about busy time and printing
The same problems will occur with busy time, printing, and any other expression of
meeting times.
Example 6: A US/Eastern user only has a one-hour noon meeting on one day in Gap
1. A Canada/Ottawa user wants to invite the US user to a 1pm meeting and checks
his busy time. The US user appears to busy between noon and 1pm only; however
he is actually busy between 1pm and 2pm in Canada/Ottawa time. If the
Canada/Ottawa user proxies the US user, the US meeting appears at noon on the
screen and in a printout.
