SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Daylight Saving Time and SQL Server

If you're in the United States, chances are you've already heard about Daylight Saving Time (DST) occurring 3 weeks early this year. This is due to the Energy Policy Act of 2005, so it's not new news, but a lot of systems and applications are only now getting the updates. The Energy Policy Act of 2005 changes DST to start on the 2nd Sunday in March instead of the first Sunday in April. In addition, it now lasts one week longer, ending the first Sunday of November instead of the last Sunday in October. For this year that means DST starts on March 11.

For the most part SQL Server isn't affected. The only SQL Server component which is happens to be Notification Services. You can find information on how to update Notification Services here:

2007 time zone update for SQL Server 2005 Notification Services and for SQL Server 2000 Notification Services (931815)

Though most SQL Server components aren't affected, the operating system on which SQL Server is installed does need to be updated (with the exception of Vista). For Windows XP and 2003 there is a patch available. You can grab the update for these operating systems here:

February 2007 cumulative time zone update for Microsoft Windows operating systems (931836)

Windows 2000, since it has passed into Extended support, does not have a publically available update. As a result, these systems must be updated by making modification to the registry. More information can be found here:

How to configure daylight saving time for the United States in 2007 (914387)

Do note that if you have Outlook on the system (such as on a workstation), there are updates to Outlook which must follow almost immediately. Outlook isn't the only Microsoft based application to be affected. To find out more information on what Microsoft applications are impacted, see here:

Microsoft Daylight Saving Time Help and Support Center

Technorati Tags: | | | | | | |

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by Tim Mitchell on 19 February 2007
Another reason that I'm thankful for being a Microsoft guy.... I have one SCO box that I have the <strike>unfortunate duty</strike> responsibility of administering, and they no longer support this particular version. The company will gladly invent a fix for me, "at an affordable hourly rate".
Posted by K. Brian Kelley on 20 February 2007
I had to test and administer SCO back in my days in the USAF (95-99). It was one of the few Unix variants that ran well on x86 server hardware and thus was the typical choice for vendors coming on the contracts who had to support the "Open Systems side." I remember similar issues with support for simple things like video drivers that were over a year old. I'm glad I don't have to support SCO any longer.
Posted by Sorry on 1 March 2007
Sorry to hear you are on a backwards OS like Microsoft.
Posted by K. Brian Kelley on 5 March 2007
Backwards OS like Microsoft? These kinds of comments, wherever I see them, amuse me. The reason being because it's all about the right tool for the job. And in this particular case, patching our Windows XP and 2003 systems were easy and didn't require a reboot... but my Red Hat Linux server did. Was it Red Hat itself that required a reboot? No, it was a potential dependency on the timezone file so a reboot was recommended. But my point is still the same: each OS has its advantages and disadvantages. Since Windows OSes are the only ones that can run SQL Server, that's an advantage, IMHO.
Posted by Dave B on 8 March 2007
You're lucky that you only have WinXP and 2003 running. If you're running Windows 2000 (server or professional), you also have to pay a significant fee (more than $4,000) to Microsoft to get the Daylight Savings update. Otherwise, you can manually modify your system according to Microsoft's 20-page document. The alternative to Microsoft's options is to use a third-party tool on your servers (not the ideal option but better than paying big bucks or running a 20-page list of instructions).
Posted by Terrence Nevins on 9 March 2007
Just to be clear as far as patching is concerned this information in comprehensive. However BEHAVIOR is another matter.

Since so many enterprises depend on Agent for so many critical tasks -- like 'backup' ;>) -- you need to consider how the time change may impact your particular situation.

I looked far and wide for the single best resource (before I tried to create my own) and was happy to find that Brian Moran did a splendid job of documenting Ron Talmage's test results.


The article title is: SQL Server Agent Got an Extra Hour of Sleep, Too

There are a number of cases where this does/doesn't apply as there are timezones and settings it seems.

The take-away is this: If you are responsible for making sure Agent completes ALL the jobs in the given window of vulnerability, you need to be watchful. If anyone makes that claim that it'll just work, don't settle for that. Be paranoid within the parameters set, think about how you can reschedule jobs to run earlier -- or later -- to completely avoid the window and be watchful.

With just a little precaution this should be a total non-event for your enterprise and your Monday will be just like any other Monday.

Terrence Nevins
Posted by K. Brian Kelley on 12 March 2007
Dave B,

No, I have a lot of Windows 2000 systems, too. We pulled the registry settings from the KB article, rolled that into a patch and applied it via UpdateExpert (from St. Bernard, now owned by Shavlik). We also had to touch a handful of NT4 servers still around... basically the same registry hack, but the top line needed to be REGEDIT4 instead of the longer 5.00 line.

All in all, the OS pieces weren't that bad. It's the apps that have caused us pause. For instance, my mobile device is running on a slightly older mobile OS. The vendor didn't provide a DST-patched version of the application for handling email/contacts (it's not ActiveSync) so I've switched the application to think it's in Puerto Rico. Those are the kinds of issues that have given us pause.
Posted by K. Brian Kelley on 12 March 2007

thanks for those comments. They bring up a good point in that any jobs during a time-change window need to be checked. There are some reports of issues with Symantec's NetBackup and APC's Powerchute and appointments in those windows. There is speculation that the java dependency (which likely wasn't handled) may be the cause. In those cases, reboots and backups didn't happen when they were expected.
Leave a Comment

Please register or log in to leave a comment.