This content is no longer maintained. Please visit our new website.

ACCC Home Page Academic Computing and Communications Center  
Accounts / Passwords Email Labs / Classrooms Telecom Network Security Software Computing and Network Services Education / Teaching Getting Help
 
2007 Daylight Savings Time Problem
Contents 1. Intro and General Information 2. Windows 3. Macs
4. Unix 5. PDAs 6. Applications 7. UICalendar

UIC ACCC: 2007 Daylight Savings Time Change

 

Last updated 2007-01-31

 
     
 
     
Daylight Savings Time
 

In 2005, the United States Congress passed the Energy Policy Act of 2005, which, among other things, changed the dates that Daylight Savings Time would begin and end in the United States, starting in 2007. Canada and Bermuda have followed suit.

Previously in the U.S., Daylight Savings Time began on the first Sunday in April and ended on the last Sunday in October. Starting in 2007, Daylight Savings Time in the U.S. will

  • begin on the second Sunday in March -- three weeks earlier than before -- and
  • end on the first Sunday in November -- one week later.

Many other parts of the world have their own change dates for Daylight Savings Time, such as Europe, which begins later and ends earlier (the last Sunday in March and the last Sunday in October, respectively), Mexico, which will continue to observe the old U.S. change dates, and the Southern Hemisphere where the seasons are opposite ours.

Also, there have always been some areas of the U.S. and Canada which did not observe Daylight Savings Time, and some of those areas continue not to, such as Arizona, Hawaii, and Saskatchewan. Indiana previously did not observe Daylight Savings Time, but now observes it.

The information in this page applies only to the U.S., Canada, and other parts of the world that are following the new dates in the U.S. Energy Policy Act of 2005.

 
     
-- The Daylight Savings Time Problem
 

The Daylight Savings Time problem is that, during the extended periods of three weeks in the spring and one week in the fall, the clocks on many systems that normally change to and from Daylight Savings Time automatically will continue to operate on Standard Time, even though Daylight Time is actually in effect. Uncorrected systems in Indiana will encounter problems for the entire summer. Clocks on uncorrected systems will not be synchronized with clocks on systems that have been fixed.

We have until the second Sunday in March, March 11, 2007, to fix this problem.

General Information about Daylight Savings Time and the 2007 Changes

US Naval Observatory: Daylight Time
Good general overview and history of Daylight Savings Time, including the 2007 changes.
Energy Policy Act of 2005
This is the law that mandated this change.
WorldTimeZone.com
Extremely useful site catalogs the time zones, and the observance of Daylight Time, for the entire world.
Wikipedia: Daylight Saving Time
 
Information Please Almanac: Daylight Saving Time
 
Interesting and confusing facts about time / time zones
 
Sources for Time Zone and Daylight Saving Time Data
Good reference, mostly oriented towards Unix, also includes a large number of excellent general links.
2007 DST Changes and Impacts on Computers
Another good general reference.
Microsoft Daylight Savings Time Help and Support Center
Covers all Microsoft products, includes latest breaking news.
IBM Daylight Saving Time alert
Good starting point for many systems, including Linux. Also has sections on hardware, application software,
 
     
1. Basic Operating Systems
 
Why you should care: All operating systems operate on the concept of keeping track of two different times. One is local time, wherever you are and under whatever rules it functions, and the other is Coordinated Universal Time (UTC), formerly known as Greenwich Mean Time (GMT). The translation between these two times is critical, and that translation process is primarily what this entire issue is about. It is your responsibility to make sure that the correct translation rules are in effect, not only so that the local time is displayed correctly, but also so that your operating system will know what the UTC time is.

Whenever two different computers communicate with one another, they do it on UTC time. Even if you have set the local time correctly, if you have the time zone wrong, or if you are still using out-of-date Daylight Savings Time rules, then your computer will have the incorrect UTC time, and your computer will have problems communicating with any other computer. These problems range from incorrect time stamps on email, incorrect time settings on your computer, authentication failure for Active Directory, to backup and restore failures. You must resist the temptation to take the shortcut of simply resetting your computer's clock; it will bite you in the end.

 
     
2. ACCC Applications & Middleware
 

None of the application software listed below can possibly function correctly, unless you first update the Daylight Time rules in the underlying operating system above.

Information for ACCC and UIC applications are below; for a more complete list, see

See also

2.1. UICalendar

The Oracle Calendar software on the UICalendar server has been updated to observe the new Daylight Savings Time change dates, so everything you enter now will be fine.

Important: However, events that you entered earlier that are scheduled to occur in the extended times of March 11, 2007 to April 1, 2007 or October 28, 2007 to November 4, 2007, may or may not be wrong by one hour.

See Daylight Savings Time Problem: UICalendar for important information about what you need to do to correct this.

If you are using Microsoft Outlook with UICal, you should not run the Microsoft Outlook Timezone Update Tool!. See below. The Microsoft Office Outlook Connector does not, itself, contain any Daylight Time issues, although it is connecting between two things which do.

2.2. Microsoft Outlook

You need to make sure that the underlying operating system is updated for the change, and then you need to update Outlook itself. Calendar events created during the extended periods of Daylight Time may appear at the wrong time. Microsoft has provided a tool to fix these problems - but do not run it if you use Oracle Connector for Outlook and UICalendar. It is OK to use the tool if you run Outlook "stand-alone" on your PC. If you run Outlook against an Exchange server, contact your Exchange Sysadmins.

However, Microsoft advises that users "should minimize the time lag between applying updates to operating systems and running the Time Zone Data Update Tool." This means that you should wait before updating Windows until you have the Outlook Time Zone Update Tool downloaded, installed, and ready to run.

Microsoft Daylight Savings Time Help and Support Center
Covers all Microsoft products, includes latest breaking news.
Microsoft Office Outlook: Prepare calendar items for daylight saving time changes in 2007
Excellent article readable by anyone, that describes the problems and the solutions very clearly. Recommended reading for all Outlook users.
Microsoft Outlook Time Zone Update Tool available here.
 
Addressing daylight saving time using the Outlook Time Zone Data Update Tool
Excellent, detailed technical documentation of all aspects of the Daylight Time problem vis-a-vis Outlook. Technical information for the technically inclined. Others should read the more general article in the first link above.
Preparing other Microsoft software products for the 2007 DST changes
 

2.3. Novell Netware (ACCC Server Services)

OES/NetWare servers in affected United States and Canada time zones should be updated with DSTShift.nlm, a Novell provided utility. TID 3397648 - Daylight Savings Time Adjustment Tool for Netware Servers

The Novell Client gets its time from the Novell Netware Server and then synchronizes the time setting on your computer with the Netware Server. Therefore, if your client computer's operating system is not patched or upgraded as specified in this document, the result could be confusion and unintended time changes when your Novell Client connects to the Novell Server and synchronizes.

Novell Netware can also run as a Java application. It uses Sun Java. See the section on Java. Also see 3980430: Daylight Saving Time (DST) defaults changing in 2007 and the impact on the NetWare Java Runtime Environment (JRE)

Links:

2.4. Blackboard Learning System

Blackboard depends on the underlying operating system and on Sun Java. Blackboard suggests running the Sun Java Updater Tool, listed above under Java Applications.

Links:

2.5. Tivoli Storage Manager (ADSM)

Though there are no Daylight Savings Time dependencies in the TSM server or client programs per se, you must insure that your own client computer's operating system is updated or patched. Failure to do that will result in session failure due to unsynchronized clocks between client and server, or time-warp errors attempting to back up files created in the future, or restore recently backed-up files which might have been backed up in the future. We have found that TSM is tolerant of a client system clock being a few minutes off, but a whole hour is too much.
 
     
3. General Considerations
   
     
-- Automatic schedulers - Unix cron, Windows Scheduled Tasks facility, etc.
  The cron facility in all Unix systems (Mac OS X, Linux, AIX, Solaris, HPUX, ...) schedules processes to be performed at specified times. A similar function is provided by the Scheduled Tasks facility in the Windows Control Panel.

The fundamental problem here is that the input data to these schedulers is specified in Local Time, so there is no way to avoid Daylight Time irregularities. (Other than running your computer on UTC.) There are two different approaches to handing the Daylight Savings Time change in these automatic schedulers:

  1. Run them twice or not at all:
    • When springing forward in the spring, events scheduled between 2:00AM and 2:59AM will not run at all. One minute after 1:59AM, it will be 3:00AM.
    • When falling back in the fall, events scheduled between 1:00AM and 1:59AM will run twice. One minute after 1:59AM, it will be 1:00AM again.
  2. Try to do what was originally intended:
    • When springing forward in the spring, all events with a frequency longer than one hour, which would have occurred between 2:00AM and 3:00AM, will be run all at once at 2:00AM Standard Time/3:00AM Daylight Time. (This may cause a short-lived performance crunch. It may also be a problem for sequencing if one program depends on the output of a previous program.)
    • When falling back in the fall, events which are scheduled to run with a frequency longer than one hour, will be run only once in the two hour time period between 1:00AM Daylight Time and 2:00AM Standard Time. They will not run a second time. Events with a frequency shorter than one hour (i.e. every 10 minutes) will continue to run at their designated frequency for the entire two hour period between 1AM and 2AM. That is, an every-10-minute event will run 12 times between 1:00AM Daylight Time and 2:00AM Standard Time.
AIX and Solaris take the first approach. Linux and Windows take the second approach. Mac OS X can do either, depending on switches you use when starting the cron process; the default for Mac OS X is the first approach.

In general, you should avoid starting critical once-a-day processes at any time between 1:00AM and 3:00AM. It may be hard to tell which approach is used on which system. Obviously though, events which are scheduled at a frequency of hourly or shorter, will not be affected by this consideration -- they will run at their expected frequency before, during, and after the time changes.

 
     
-- Multi-Boot Systems
  Which system owns the hardware clock? (Probably both.) What does it do with it? When does it change it?

If you have a dual-boot, multi-boot, or virtual machine arrangement on your computer that allows you to run multiple operating systems, you've got to make sure they are not interfering with one another regarding your computer's hardware clock.

A very basic problem is that Windows (all versions, from DOS to Vista) operates with the hardware clock set to local time, while Unix (all versions, including Linux and Mac OS X) operates with the hardware clock set to UTC (Greenwich) time.

The other basic problem is that when any Windows system changes to or from Daylight Time, it resets the hardware clock to the new local time. If you then boot a second Windows system on the same computer, it will change the hardware clock again, for a total of a two hour change. If the second system is Unix, it will get very confused.

One simple solution to this is to run all systems on UTC. See Moving to Greenwich below.

The more realistic solution is to have your most frequently-used system handle the Daylight Savings time change, and tell the others not to. This solution works well if both systems are Windows.

If you are mixing Windows and Unix, such as running Windows and Mac OS X on an Intel-processor Mac, then you should probably run the Windows on UTC, while you can run the Unix however you want. This way, neither system is tinkering with the hardware clock at Daylight Time changes. There is also a registry hack around to make Windows NT/2000/XP run with the hardware clock set to UTC, however it has been found to be unstable in actual use. It is not known if this hack has been made to be reliable in Vista.

 
     
-- Time Interval Calculations
  What is the exact length of time between 12:00 Noon Local Time on March 1 and 12:00 Noon Local Time on March 15? That will vary by one hour, depending on the year.

What is the exact length of time between 12:00 Noon Local Time on March 1, 2006 and 12:00 Noon Local Time on April 10, 2007? That will vary by one hour, depending on which part of Indiana you are in. In a few parts of Indiana such as Evansville, offsetting errors may accidentally yield a correct answer.

If exact time intervals are important to you, such as in a lab experiment that counts the frequency of certain events over some period of time, then you should seriously consider using the UTC (GMT) time zone throughout. Otherwise you may find yourself trying to figure out why those cells completely stopped dividing for one hour at 2:00AM on March 11, 2007. See the section on Moving to Greenwich below.

 
     
-- If All Else Fails, Move to Greenwich, England
  Greenwich (pronounced "GREN-itch") is a pleasant, leafy, suburb of London, that overlooks the Thames River as it makes its way from London to the sea. Greenwich is home to the Royal Observatory, which first standardized the global measurement of time in the 18th Century. As ships passed by on their way out to sea, they would synchronize their clocks to the time at the Royal Observatory. This was crucial to navigation, because calculating the time difference between solar noon at Greenwich, and solar noon anywhere else on earth, was the first reliable method of determining your longitude, and thereby your exact position on earth. The Prime Meridian, 0 degrees longitude, runs through the Royal Observatory building, and solar time on the Prime Meridian, originally called Greenwich Mean Time (GMT) but now called Coordinated Universal Time (UTC), remains the standard today for worldwide time-keeping.

If the system you have cannot easily be fixed to observe the new change dates for Daylight Savings Time, you could always set that system to run all year on UTC/GMT. Many organizations, especially those with worldwide operations, operate all their computing systems on UTC. This completely avoids the issues of Daylight Savings Time or the latest changes to the dates it is observed.

When doing so, some systems (Windows, Mac) force you to select a time zone as it is observed in a particular location. In that case, do not select London or any other location in Europe, because all of Europe observes Daylight Savings Time. On these systems, select a western African location, such as Monrovia Liberia, because these places do not use Daylight Time. They observe UTC all year round.

When setting your clock on a system configured to operate on UTC, remember to set the correct date also. During the evening in Chicago, it is tomorrow in the UTC time zone, so set the correct UTC date too. The www.time.gov time service has a UTC option you can select, to display the current time and date in the UTC time zone.

Alternatively, many systems can be configured to be switched manually between Standard Time and Daylight Time. For instance, the page on Windows contains instructions that are generally applicable to any Windows system. Instructions for manually switching Mac OS X are in the page on Macs.

 
     
-- What time is it in Indiana?
  In 2005 and before, time zone and daylight time observance differed from one county in Indiana to the next, and the question, "What time is it?" was complicated to answer, requiring reference to both a map and a calendar. Brochures were available at locations such as toll road plazas explaining it all.

In a major simplification, all of Indiana started observing Daylight Savings Time in 2006. However the state remains divided between the Eastern and Central time zones, with the greater Gary and Evansville areas observing Central Time. Even with that remaining division, it is now quite a bit easier to tell time in Indiana.

Links:

Wikipedia: Time in Indiana
 
Time Zone map of Indiana (PDF) (Get free Adobe Reader Here)
Official map provided by the Indiana State Government.
Microsoft Knowledge Base 914837:
Description of issues that are related to time zone changes in Indiana
 
     
-- What time is it right now?
  The Official U.S. Time Clever java-powered web site from the U.S. Government displays the current time to within a tiny fraction of a second, by measuring and compensating for network delay. This public service is cooperatively provided by the two time agencies of the United States: a Department of Commerce agency, the National Institute of Standards and Technology (NIST), and its military counterpart, the U. S. Naval Observatory (USNO). Readings from the clocks of these agencies contribute to world time, called Coordinated Universal Time (UTC). The time maintained by both agencies should never differ by more than 0.000 0001 seconds from UTC.

On that page, click the link "About this service" for a page of more information, including links to programs to automatically set your computer's clock to the correct time.

 
     
-- Automatically setting your clock with NTP
  The Internet Network Time service, or NTP, is a way to automatically synchronize your computer's clock with the correct time standard maintained by the government. It is widely used. For instance, Macintosh computers have it configured by default.

When your computer asks a handy NTP server what time it is, the answer is always in the UTC (Greenwich) time zone. Your computer then translates that into Local Time.

The problem is, that if your computer does not have the correct time zone calculations, it will be set to the wrong time.

 
     
-- Is it Daylight "Savings" or "Saving"?
  I mention this only to deflect some of the inevitable flames that will be directed my way for using it both ways. Both grammatical forms are in common usage, and are therefore both correct. There has been an especially animated discussion on http://www.slashdot.org about this distinction, to which you are referred if you want to argue either side of this issue.
Author: Roger Deschner rogerd@uic.edu

Did you know that Time Zones were invented here in Chicago, by the railroads?

 
DST Problem Previous:  Contents Next:  2. Windows


2010-12-8  ACCC documentation
UIC Home Page Search UIC Pages Contact UIC