Article ID: 931975
Article Last Modified on 11/20/2007
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
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.
| Date when DST previously started | Date when DST starts in 2007 | Date when DST previously ended | Date when DST ends in 2007 |
|---|---|---|---|
| First Sunday in April | Second Sunday in March | Last Sunday in October | First Sunday in November |
| Would have been April 1, 2007 | March 11, 2007 | Would have been October 28, 2007 | November 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:
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
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.
Keywords: kbhowto kbinfo kbexpertiseadvanced kbsql2005engine KB931975
