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):
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
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: