How to prepare SQL Server 2005 and SQL Server 2000 for changes to daylight saving time in 2007

Article translations Article translations
Article ID: 931975 - View products that this article applies to.
Expand all | Collapse all

On This Page

INTRODUCTION

In August 2005, the U. S. Congress passed the Energy Policy Act. This act changes both the start date and the end date of daylight saving time (DST). When this act goes into effect in 2007, DST will start three weeks earlier and will end one week later than when it traditionally started and ended. Specifically, DST will start at 2:00 A.M. on the second Sunday in March and will end at 2:00 A.M. on the first Sunday in November.

The following table summarizes the changes to daylight saving time in 2007.
Collapse this tableExpand this table
Date when DST previously startedDate when DST starts in 2007Date when DST previously endedDate when DST ends in 2007
First Sunday in AprilSecond Sunday in MarchLast Sunday in October First Sunday in November
Would have been April 1, 2007March 11, 2007Would have been October 28, 2007November 4, 2007
This article discusses how to prepare Microsoft SQL Server 2005 and Microsoft SQL Server 2000 for the changes to DST in 2007.

MORE INFORMATION

Actions that you must take

If you have SQL Server installed on a computer that is configured for automatic DST adjustments, and the time zone of the computer follows the changes to DST in 2007, you must take the following actions:
  • Install the update for Windows that is described in Microsoft Knowledge Base article 924840. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    924840 A test version of the 2007 global time zone update for Windows is available
  • If you have SQL Server Notification Services installed on the computer, install the update that is described in Microsoft Knowledge Base article 931815. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    931815 2007 time zone update for SQL Server 2005 Notification Services and for SQL Server 2000 Notification Services
  • You do not have to apply any specific updates for SQL Server to make sure that SQL Server works correctly. However, you must update the operating system. Additionally, you must update the products and applications that interact with SQL Server. These products and applications may include Notification Services, Windows SharePoint Services, Microsoft CRM, and so on. For a complete list of updates that you must apply for other Microsoft products, visit the following Microsoft Web site:
    http://support.microsoft.com/gp/cp_dst

SQL Server time usage and reporting

In SQL Server 2005 and in SQL Server 2000, the SQL Server database engine uses the following two forms of timer to generate time information:
  • High-resolution timer
  • Low-resolution timer
In the high-resolution timer, the timer resolution is based on the Read Time-Stamp Counter (RDTSC) instruction of the CPU. In the low-resolution timer, the timer resolution is based on the GetTickCount function in the Microsoft Windows API.

Various timer-based background tasks and critical system components rely on these timers for their correct functioning. Because these timers work as relative measures from a specific time, internal components and internal activities will not be affected by the changes to DST in 2007.

For example, you perform tasks that involve the following timer-based activities or timer-based components:
  • System components such as lazy writer, lock monitor, and scheduler monitor
  • Background tasks such as ghost cleanup and auto-shrink
  • Time-out-based resources such as locks and latches
  • Scheduled activities such as SQL Server Agent jobs and maintenance plans
  • System statements such as the WAITFOR statement
SQL Server also generates time information that is made available to external components and applications. This time information is retrieved from the Windows operating system. Therefore, the time information is accurate as long as the operating system returns the correct time value.

For example, you perform tasks that involve the following external components and applications:
  • SQL Server Profiler or SQL Profiler event columns such as the Start Time column, the End Time column, and the Duration column for various events
  • Time information that is reported in various logs such as the SQL Server Errorlog, event logs, and system tables
  • System functions such as the GetDate function and the GetUtcDate function
Consider the following scenario. You create a SQL Server trace by using SQL Server Profiler or SQL Profiler. The trace records a query that starts before the March 2007 DST time change and finishes after the March 2007 DST time change. In this scenario, the time information is accurate and is not affected by the DST changes.
The following is the sample output of the trace:
EventSequence  EventClass         TextData              StartTime                EndTime                  Duration
156            Sql:StmtStarting   Select * From Table1  2007-03-11 01:59:57.187
157            Sql:StmtCompleted  Select * From Table1  2007-03-11 01:59:57.187  2007-03-11 03:00:07.187  9987
Similarly, the following is the sample output of a trace that records a query during the November 2007 DST time change:
EventSequence  EventClass         TextData              StartTime                EndTime                  Duration
178            Sql:StmtStarting   Select * From Table1  2007-11-04 01:59:54.967
179            Sql:StmtCompleted  Select * From Table1  2007-11-04 01:59:54.967  2007-11-04 01:00:05.030  10055

Known DST-related SQL Server issues that are not specific to the changes to DST in 2007

DateDiff and DateAdd date and time functions are not DST aware

When you use Transact-SQL statements to perform time calculations that are based on system-provided date and time functions, you must carefully investigate the statements. Specifically, if you have written DST times in hard code in the application logic, the DateDiff and DateAdd system functions are not DST aware.

For example, an application runs the following statements to calculate the time difference. The calculation is based on the old DST time. Notice that under the new DST system in 2007, 2007-03-11 is the starting date of DST. However, under the old DST system, 2007-04-01 would be the starting date of DST.
DECLARE @starttime datetime
DECLARE @endtime datetime
SELECT @starttime = GetDate() -- returns '2007-03-11 1:59:50.000'
WAITFOR DELAY '00:00:30'
SELECT @endtime = GetDate()   –- returns '2007-03-11 3:00:20.000' 

If @starttime < '2007-04-01 3:00:00.000' And 
   @endtime > '2007-04-01 1:59:59.000'
	SELECT (cast((DATEDIFF(s, @starttime, @endtime)) as int) - 3600) AS TimeDiffInSecs
Else
	SELECT cast((DATEDIFF(s, @starttime, @endtime)) as int) AS TimeDiffInSecs

Go
When you run the statements, you receive the following result:
TimeDiffInSecs 
-------------- 
3,630
Because the DateDiff system function is not DST aware, the statements return 3,630 seconds instead of 30 seconds.

To correct the time calculation in such scenarios, use the GetUtcDate function instead of the GetDate function. The GetUtcDate function returns the current UTC time. The current UTC time is derived from the current local time together with the time zone setting in the operating system of the computer on which SQL Server is running.

The following are modified statements that work correctly:
/*-------------------------------------------------------
	  GetDate()		  GetUtcDate()
datetime  2007-03-11 1:59:50.000  2007-03-11 09:59:50.000
datetime  2007-03-11 3:00:20.000  2007-03-11 10:00:20.000
-------------------------------------------------------*/
DECLARE @starttime datetime
DECLARE @endtime datetime
SELECT @starttime = GetUtcDate() -- returns '2007-03-11 9:59:50.000'
WAITFOR DELAY '00:00:30'
SELECT @endtime = GetUtcDate()   –- returns '2007-03-11 10:00:20.000'  
SELECT DATEDIFF (s, @starttime, @endtime) AS TimeDiffInSecs
Go
When you run the statements, you receive the correct result as follows:
TimeDiffInSecs 
-------------- 
30

Effect of the DST end date on scheduled SQL Server Agent jobs

Consider the following scenario. You have a scheduled SQL Server Agent job that prints current local time. The job runs every 15 minutes. When the DST change occurs in November 2007, SQL Server Agent automatically tracks the DST change. SQL Server Agent bases its tracking on the operating system and updates the next scheduled run of the job correctly.

The following is the sample output of the job:
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 01:30:00
CurrentTime    2007-03-11 01:30:00.343

Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 01:45:00
CurrentTime    2007-03-11 01:45:00.343

Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 03:00:00
CurrentTime    2007-03-11 03:00:00.357

Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-03-11 03:15:00
CurrentTime    2007-03-11 03:15:00.357
In this example, there is a one-hour gap between the run of the job at 2007-03-11 02:00:00 and the run of the job at 2007-03-11 03:00:00 as expected.

However, there is a known issue in which scheduled SQL Server Agent jobs cannot run for one hour during the period when the November 2007 DST change occurs. After the clock is changed back from 2:00 A.M. to 1:00 A.M. on November 4, 2007, SQL Server Agent jobs would skip the next hour and wait until 2:00 A.M. to start next run. This is a known issue. This issue occurred even under the pre-2007 DST conventions. This issue does not result from the changes to DST in 2007.

The following is the sample output of the job:
Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 01:30:00
CurrentTime    2007-11-04 01:30:00.343

Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 01:45:00
CurrentTime    2007-11-04  01:45:00.343

one hour plus 15 minutes gap here */

Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 02:00:00
CurrentTime    2007-11-04 02:00:00.357

Job 'Daylight Savings Job 1' : Step 1, 'step 1' : Began Executing 2007-11-04 02:15:00
CurrentTime    2007-11-04 02:15:00.357
Notice that in the sample output of the job, there is a one-hour-and-15-minute gap between the run of the job at 2007-11-04 01:45:00 and the run of the job at 2007-11-04 02:00:00. This behavior could affect the replication agent jobs, the backup jobs, log shipping jobs, and other scheduled jobs in SQL Server.

Properties

Article ID: 931975 - Last Review: November 20, 2007 - Revision: 3.5
APPLIES TO
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard X64 Edition
  • Microsoft SQL Server 2005 Standard Edition for Itanium-based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium-based Systems
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000, Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Enterprise Edition 64-bit
Keywords: 
kbhowto kbexpertiseadvanced kbsql2005engine kbinfo KB931975

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com