2007 Time Zone Patches for Computers in Canada, the U.S. and Bermuda





Jeff Regan




Last Updated: 2008 09 01


Year

DST Begins: usually at 2AM

(Some locations may switch at midnight or 1AM)

DST Ends: usually at 2AM

(Some locations may switch at midnight or 1AM)

2008

March 9

November 2

2009

March 8

November 1

2010

March 14

November 7

2011

March 13

November 6

2012

March 11

November 4

2013

March 10

November 3

2014

March 9

November 2

2015

March 8

November 1



Table of Contents



Daylight Saving Changes in 2007 and the Impacts

by Jeff Regan


In 1999, there was much concern about the impact of software's inability to switch from years starting with 19 to years starting with 20.  A lot of effort was put in place to virtually eliminate the issue by the time the year 2000 came along.

There is a new risk for many businesses that has some similarities to the Y2K bug, but is not actually a bug at all.

Last year, in an attempt to reduce energy consumption, the US Congress, in section 110 of the "Energy Policy Act of 2005" announced plans to move the start and ending dates of Daylight Saving time to give more light in the evenings for a longer period of the year.  All of Canada (except the regions that never change their timezone at all during the year) will follow the U.S. plan as well.  Bermuda has announced a similar plan.

In 2007 (and the years following), Daylight Saving Time will start on the second Sunday of March instead of the first Sunday of April.  It will end on the first Sunday in November, instead of the last Sunday in October.

Businesses, and individuals who use any hardware or software that is sensitive to date and time transactions, and utilizes a local time zone, or interacts with systems that use a local time zone (versus the universal UTC time zone used for many world wide business transactions) could be impacted by these changes in Daylight Saving Time.On your typical computer server or PC, the automatic decision to change to Daylight Saving time is generally made by the underlying Operating System, such as Microsoft Windows or Unix.  However, applications often also perform date and time manipulation, and may make a similar automatic decision, or use date/time calculations in other ways.

In Melbourne, Australia, a recent similar change to Daylight Saving Time was temporarily made as to avoid reverting back to Standard Time during the XVIII Commonwealth Games.  During this time, IT support had to deal with several impacts, including calendar schedules being out of sync by one hour (especially when trading calendar details with other people in different parts of the world who had not introduced any patches) and inaccurate security logs that were off by one hour, calling into question their legal validity.  Other impacts included automated events and transactions such as end of day procedures that must occur at midnight running at the wrong time. 

For the average home user, the impacts were not as critical, but included events such as a TV program being recorded at the wrong time, or Internet parental blocks (as programmed into their DSL router) that limit a child's use of the Internet after certain hours starting at the incorrect time.  Some alarm panels and even bank vaults locking/unlocking times will have to be dealt with too, or some businesses may open an hour late on the first day back after the change.

Generally, before March of 2007 patches will be available for currently supported Operating Systems.  This means that older operating systems such as Windows NT, Windows 95, or any Sun Solaris version before 2.8 won't have official patches made available for them.

Older unsupported Unix versions (such as older Solaris or Linux versions) can have non-supported patches applied to them, as they generally all utilize a common time methodology called "Zoneinfo".  Updates to the Zoneinfo files are available on the Internet and can be applied to these older Unix Operating Systems.

After the OS has been dealt with, each application must also be examined and tested to understand if there is date/time sensitive code within. This also applies to stand alone hardware such as network devices, routers, switches and even some alarm panels.  Appropriate upgrades or patches may also be required in these instances.

Research needs to be done in all areas of an organization to ensure that in March 2007 time is as time should be.  This should include an analysis of how time related events and time manipulation occur in all hardware and software devices, software applications and the interaction between them. Just as with Y2K, each system will need to be tested to ensure it passes handling the change into and out of Daylight Saving time on the correct dates/times in years past 2006, as well as correctly calculating any calendar related information into the past and future.

And if the energy saving don't come forward, the US Government reserves the right to further change the DST timetable again down the road, creating more work in the future.

Depending on complexities in your business, a few patches from your software and OS vendors will fix this concern with little or no interaction on your part.  However, on the other hand, this could involve a lot of work, involving many individuals.  Start now so there is enough time to evaluate the impacts, and get the appropriate upgrades, patches or coding changes made.  Otherwise, March 11, 2007 may be a little more stressful than a typical Sunday.

Back to Table of Contents



Summary of New 2007 DST Period in Canada / U.S. / Bermuda

"Spring Forward" one hour into DST will commence:
The Second Sunday of March (was First Sunday of April - 3 weeks early)

In 2007, this will be on Sunday, March 11 @ 2AM.


"Fall Back" one hour into Standard Time will commence:
The First Sunday of November (was Last Sunday of October - 1 week late)

Back to Table of Contents


Summary of Impacts

Any electronic device that uses time, or has a calendar type function in it will need to be patched or upgraded to prevent everything from minor inconveniences to more serious problems.  The first impacts will be felt March 11, 2007 when Daylight Saving Time will start 3 weeks early.

Back to Table of Contents



High Level Impacts


Many programming languages (such as Java) use their own time conversion routines.   Application Support Libraries may need to be updated.

Stand alone embedded devices such as DSL Routers, Alarm Panels, PVRs and maybe even your car (if it has a tie into GPS, alarm locaters, etc.) may be configured with time dependent rules and automatic time zone adjustments, requiring an image upgrade.

If you are in a time zone that does not switch into Daylight Saving Time, you may still have to patch applications if you software communicates with systems that are in those time zones.  For example, calendar and scheduling programs, for example.  Otherwise, you may find that you for a conference call an hour early or an hour later than other members of your call.

Back to Table of Contents


How To Eliminate The Risk of this New Daylight Saving Schedule

There are several different ways to mitigate the risks with this change.  

Do you need to even install any patches at all?  Is it a big deal if your computer is out by an hour or two for 4 or 5 weeks of the year?

In many cases, the answer to this is 'yes, it is a big deal'. 

However, how much does it matter?  You have to consider how your servers interact with other servers and devices.  

Research what will break come March 11, 2007.

First off, you have to understand how your servers use the date and time. 

Do your applications use date/time for calendars and scheduling?  Or are you doing simple word processing, so it is only important that you have a correct date and time on the file timestamp?

Do your applications talk to other servers for various reasons? 


Calendar / Scheduling Software

Some Calendar programs may be confused and will incorrectly show the time (one hour behind) for events during the three week period in the spring, and one week period during the fall.  Microsoft, for example, has patches available to help mitigate this issue, but they recommend that both the Windows and Outlook client patches on the user's PC, as well as the Exchange server work all be completed at about the same time to further reduce the risk of appointments being out by one hour.

Keep in mind that even if you have a PC in a time zone that will not make this DST change (Saskatchewan, for example), you should still patch the PC, so the PC knows of any incoming scheduled appointments that user's might receive from others in areas that are impacted by the DST change.

Upgrading PC and server OS and Applications - What are the impacts?


- What if no patches are being made available for your OS version?  For Unix PCs and Servers, this fix is easy, and is discussed further down in the section on Zoneinfo files.  For other operating systems, an OS upgrade may be required.

- What if no patches are being made available for your Application?  Unless you require specific scheduling or calendar software, you may only need an OS upgrade.

- Will a patched or upgraded version of your application work with the patched or upgraded version of the operating system?  What about other software that on the same system? 

Data Between Servers


Even if you patch your OS and Applications on your servers, you have to consider what happens to any data you receive or send to other servers.

Some questions to think about:
  
- Are system logs, authentication logs, application logs sent or received from other servers or devices?  What happens if all these servers are not patched?  If you had to use some of your logs in a court of law, could you without a doubt say what time zone those logs were displaying?

- Do you have any scheduled events or cron entries that need to run at a particular time?  What happens if they run an hour early or an hour late?  Will data be lost?  Will backups fail?

- Do you run any applications that produce billing or charge certain costs based on a time of day automatically?  If this is out of sync, what is the impact to your customers?

Manually Changing the Time On March 11th Will Not Work

You can't find a patch for your OS or Application?  You are considering trying to 'set the time by hand'?

Setting the time by hand on March 11th will not work in most instances.  Not only will you then have to do it three more times during the rest of the year (3 weeks later, and again twice in the fall), your computer will also not really be at the correct time.  For example, 12 Noon EST = 12:00 EST = 13:00 DST = 17:00 GMT.  Those represent the exact same time, stated in different ways.

If you try and set your computer on March 11th, most unpatched (for DST 2007) Operating Systems will know you should still be in EST, and you will just be putting them one hour ahead.  

In most cases, the transition on March 11th goes from 01:59:59 standard time, to 03:00:00 daylight saving time.   An unpatched computer would show 02:00:00 EST.  If you try and set the time by hand, in most instances, you will only be able to set it to 03:00:00 EST.  Yes the hour will be correct, but the timezone will be wrong.  (Some versions of Windows allow you to override the DST setting, but you still have to deal with it four times per year, and in most cases, there are already patches available anyhow).  And if you have an NTP client on the computer (as most Windows and Unix servers do these days) that keeps the computer time correct (computers are no good at keeping accurate time on their own), it will no longer run (letting the time drift by seconds or minutes per day), or it could just go and change the time back on you, since its job is to keep your computer time c orrect in the first place.  And, as mentioned above, you will have to deal with this 3 more times this year.  And four times every following year until you upgrade or retire the server.

In this instance, it might be better to leave the computer alone and live with the wrong time, but at least a time that is expected, and still synced to your NTP server.  The time, while in the wrong time zone will represent the real time, just represent it in a timezone someone might not expect to see when everyone one else has moved into Daylight Saving Time.

Another alternative is to switch servers to GMT time, as described below.

What About Setting Your Servers to GMT (Greenwich Mean Time)/Co-ordinated Universal Time?

If your company has offices and/or servers located in different time zones, it might just be easier to move everything to GMT/UTC.  In this case, the servers would never change into DST, and you may be able to avoid patching them.   Some applications allow the users to pick what time zone they want to see, and if that was the case you would still need to patch the applications.

It also means that when you looked at the date and time, or date/time stamps from the server, it would always be different than your local time.  For example, in Ontario, Canada, and much of the Eastern United States, GMT/UTC time is 4 hours ahead during the summer when EDT is in place, and 5 hours ahead during the rest of the year.

This has the advantage of removing the impacts from local time zone changes.  It also means that in a national or international company, everyone uses a common time for their servers, and there is never any question as to how time is configured.

Embedded Devices

Devices such as DSL Routers, Alarm Systems, Pocket Organizers, VCRs, etc. are devices that aren't a typical computer, but they still understand dates and times.

In some cases, the date and time are not critical.  DSL Routers probably don't need the date and time set on them, unless you have them scheduled to activate and deactivate on a schedule.   This could be used to limit the hours when children can use the Internet at home, for example.

If you determine that accurate date and time are needed, and if the device automatically adjusts for Daylight saving time, then you will need to contact the company that made the product and get a firmware update.  Start with their web page and contact technical support.

Note: some devices, especially some VCRs, set their time and date automatically via U.S. PBS stations.   So in that case you will have to trust that the time source is adjusted correctly, and if it is not, set the time manually.

Computer Hardware

In most cases, bios updates to a typical desktop computer will not be required.

On servers (such as Sun's E6800 servers, for example), and on some Disk Storage Arrays/SANs, if they have a date/time of day clock as part of Integrated Lights Out Management (ILOM), the bios may need to be upgraded.

Some details from Sun can be found here.


JAVA - SUN

The Java Runtime Environment (JRE) stores rules about DST observance all around the globe.  Applications may report the wrong time after March 11, 2007.

Sun has posted fixes for both their OS, and JAVA. 

So far it has required an upgrade to the JAVA runtime environment:
https://java.sun.com/developer/technicalArticles/Intl/USDST/

https://www.sun.com/bigadmin/features/techtips/dst_changes.html

However, there is another option available:

JDK DST Timezone Update Tool   

https://java.sun.com/javase/downloads/index.jsp
 
For JDK v1.4 and 5.0 and 6 this will avoid the need to do the full updates.

JAVA - IBM

The JTZU Version 1.1.7a Time Zone Update Utility for Java can be found at:

https://www-128.ibm.com/developerworks/java/jdk/dst/

IBM - Check IBM Applications

"This site will help you find the necessary information for affected products, so that you can plan updates to help reduce the risk of application and system failure resulting from this change."

https://www.ibm.com/support/alerts/daylightsavingstimealert.html

Databases - Oracle


If your Oracle databases are using the TSLTZ or TSTZ variable,  they will require updates to the associated local timezone files.

Oracle Metalink Note:357056.1 "Impact of changes to daylight saving time
(DST) rules on the Oracle database" explains the situation.




Back to Table of Contents



High Level Look at Different Operating Systems:



Microsoft:

Microsoft's Web site on the topic can be found at:

https://www.microsoft.com/windows/timezone/dst2007.mspx

and

https://support.microsoft.com/kb/928388

To avoid scheduling errors with Outlook, the first link above shows some detailed steps that need to be followed to help reduce the risk.

Older unsupported OS versions won't have patches produced for them to deal with this change.  The solutions are::
- upgrade to a new OS
- change the server to run in GMT/UTC.
- put up with the wrong time

Other recent patches:

Since March 2007, a number of issues have been identified that will necessitate the deployment of additional fixes for C Runtime Libraries, Java Scripts, Visual Studio products and Microsoft Java Virtual Machine

KB932590 - C Runtime Library Patch
KB933811 - Jscript Patch

KB931836 - Updated DST Patch (Feb. 2007)

Windows NT


While NT is not supported, there may be a work around if you have a server or PC you can't upgrade.

Windows NT cannot handle more than one set of Daylight start and end dates. Once the value is changed it can effect time and date calculations in calendars and other  applications
https://support.microsoft.com/kb/909915/

Corrections to Windows NT systems will have to occur after October 28, 2006 but before March 11, 2007, with knowledge that backward calculations of time using system facilities may calculate time setting incorrectly.


Windows 95/98/ME

There is no official Microsoft patch available for Windows 95, 98 or ME.  However, an unofficial method can be found here.  As with any patch, be sure to test it before you roll it out on your production computers.

Back to Table of Contents

Windows 2000

No patch is available for Windows 2000.  However an update is available for Service Pack 4 to those with an Extended Support Hotfix Agreement from Microsoft.

There is also an unofficial patch for Windows 2000 available here.  As with any patch, be sure to test it before you roll it out on yuor production computers.

Back to Table of Contents


Windows XP

Service Pack 2 has a patch available (see above).  It is not clear when the patch will be distributed via Windows Update.

Back to Table of Contents


Windows 2003

Windows 2003, and Windows 2003 Service Pack 1 have patches available.  See the Microsoft links above.

Back to Table of Contents

Windows Vista

No patch is required for Windows Vista.  It comes with the patches preinstalled.  However, it would not hurt to verify this to ensure no issues crop up.

Back to Table of Contents


Apple MAC OS X

The OSX patch can be obtained from here:

https://docs.info.apple.com/article.html?artnum=303411

Back to Table of Contents

Red Hat Linux

The Red Hat patch can be obtained from here:

https://rhn.redhat.com/errata/RHEA-2005-656.html

Ubuntu Linux

The Ubuntu patch can be obtained from here:

https://packages.ubuntu.com/edgy/libs/tzdata

Back to Table of Contents

Unix (Linux, Solaris, etc.)


Formal patches will be made available on supported OS versions. 

However, Unix is flexible enough that even older OS versions (Solars 2.4 for example) can have simple fixes applied to them.



Any system using the Zoneinfo format, (GNU/Linux, Cygwin, FreeBSD, NetBSD, OpenBSD, Mac OS X, HP-UX, IRIX, Solaris, Tru64, UnixWare. OpenVMS) can be updated manually using the 'zic' time zone compiler.

How to build the Unix Zoneinfo Time Zone Files Manually


Build binary zone files:

1: download the latest copy of ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz.  This will include the details of the DST change.  You could also update the source files by hand  i.e.: /usr/share/lib/zoneinfo/src in solaris

2: view file to ensure necessary changes have been made.

3: compile the binary zone file per the instructions of the time zone compiler 'zic' which comes with the system.

4: install the new binary zone file over the current zone file, making sure all symbolic links, etc, are updated as needed.



Sun Solaris Patches


SPARC Platform
Solaris 8 with patches 109809-02 or later and 108993-52 or later

Solaris 9 with patches 113225-03 or later and 112874-33 or later

Solaris 10 with patches 122032-01 or later and 119689-07 or later

x86 Platform
Solaris 8 with patches 109810-02 or later and 108994-52 or later

Solaris 9 with patches 116545-02 or later and 114432-23 or later

Solaris 10 with patches 122033-01 or later and 121208-03 or later

There is also some info on the Posix / libc patches, which can be found here.

Unofficial Solaris 2.51, 2.6 and 2.7 patches can be found here.  As with any patch, be sure to test it before you roll it out on yuor production computers.



Back to Table of Contents


HP-UX Patches


PHCO_34673 s700_800 11.00 tztab(4) cumulative patch

PHCO_34668 s700_800 11.11 tztab(4) cumulative patch

PHCO_34669 s700_800 11.23 tztab(4) cumulative patch

HP-UX 11i v3 will have the patches in it when it ships.

Quality packs containing the above patches can be downloaded from:

https://itrc.hp.com/service/patch/releaseIndexPage.do?BC=main|bundle


Back to Table of Contents


BlackBerry Patches


Patches will be needed to keep the device's time correct:

https://www.blackberry.com/select/dst2007/index.shtml


Back to Table of Contents



Lessons Learned From Previous Daylight Saving Time Changes


During the XVIII Commonwealth Games, it was decided to delay returning to standard time until the games were over.  This caused many issues on servers.  Here is one System Administrators view of what happened.

https://stilgherrian.com/internet/daylight-saving-chaos/



Back to Table of Contents



Energy Policy Act of 2005 Section 110. Daylight Saving Time Details:

SEC. 110. Daylight Saving.

    (a) Amendment.--Section 3(a) of the Uniform Time Act of 1966 (15 U.S.C. 260a(a)) is amended--
            (1) by striking ``first Sunday of April'' and inserting ``second Sunday of March''; and
            (2) by striking ``last Sunday of October'' and inserting ``first Sunday of November''.

    (b) Effective Date.--Subsection (a) <<NOTE: 15 USC 260a note.>> shall take effect 1 year after the date of enactment of this Act or March 1, 2007, whichever is later.

    (c) Report to Congress.--Not <<NOTE: 15 USC 260a note.>> later than 9 months after the effective date stated in subsection (b), the Secretary shall report to Congress on the impact of this section on energy consumption in the United States.

    (d) Right to Revert.--Congress retains the right to revert the Daylight Saving Time back to the 2005 time schedules once the Department study is complete.



Note from Jeff:

So you may have to undo all your hard work a year from now, if they chose to move back to the pre 2007 DST dates.


Back to Table of Contents



Regional Daylight Saving Times position statements in Canada


As of May 18, 2006, almost all provinces and territories will be aligning Daylight Saving time to the changes being made in the U.S.A.

Except for Saskatchewan (which continues not to practice Daylight Saving Time), all of Canada (including  Newfoundland, Yukon and Nunavut) has announced plans to follow the new DST 2007 timetable

Additional details can be found here:
https://inms-ienm.nrc-cnrc.gc.ca/time_services/daylight_saving_e.html

Official references regarding 2007 daylight changes per province (note: may now be out of date):

British Columbia

Alberta

Manitoba

Ontario

Quebec

New Brunswick

Nova Scotia

Prince Edward Island



Back to Table of Contents



Other References

The White House Press Release on DST Changes

Greenwich Mean Time reference to the policy

Wikipedia's Reference to DST

Related Side Topics

Western Australia to Start Three Year Daylight Saving Trial as of December 2006.



Back to Table of Contents


Closing Comments

I have done my best to keep the information on this site accurate.  However, if you find any errors, or can provide any more useful information, please let me know.  You can email me at 'jeff @ reganfamily.ca'.  

Thank you to everyone who has already provided me with comments and input.

Back to Table of Contents


Visitors to site: