Key US Daylight Savings Time Information
Just had got some great very complete information from product support about the upcoming Daylight Savings Time change and how it does or doesn't impact you. I did a post on DST previously, but this has much, much more info. (Thanks Dan and Bruce!)
SHAREPOINT DST QUICK INFO:
======================
The prior DST dates were April 1st @ 2:00 AM (Sunday of 4th month, 1st week) and October 28th @ 2:00 AM (Sunday of 10th month, 5th week).
The new DST dates are March 11th @ 2:00 AM (Sunday of 3rd month, 2nd week) and November 4th @ 2:00 AM (Sunday of 11th month, 1st week).
As such, there are two time periods (deltas) this year where there is a discrepancy between prior DST time changes and new ones.
March 11, 2007 at 2:00 A.M. through April 1, 2007 at 2:00 A.M. (from the start of the new DST through the start of the old DST) is the first zone (3 weeks).
October 28, 2007 at 2:00 A.M. through November 4, 2007 at 2:00 A.M. (from the end of the old DST through the end of the new DST) is the second zone (1 week).
If left alone, many products will behave as though the prior DST dates are still in effect and be an hour off of the actual time until the prior DST date is reached.
To correct this, many patches have been created. Here is the information you need to know for SharePoint.
All SharePoint products require that OS patch 931836 is applied to the server.
If other environments that SharePoint interacts with are not patched and SharePoint is—this could lead to issues with new data creation. Manual adjustments may be necessary in this scenario.
The primary SharePoint patch is WSS update 933738. The KB is at:
http://support.microsoft.com/?kbid=933738
It points to the download to the needed patch:
http://www.microsoft.com/downloads/details.aspx?familyid=3e6ade34-06ee-4e69-88d1-a7e0461b71da&displaylang=en
The download page for the patch refers to both KB934000 and KB 933738. The actual patch is labeled: WSS2003-KB934000-GLB.exe
The KB934000 is what is known as a “Roll-up” KB. This will be automatically generated and will show all of the fixes that are included in this update.
In other words, there are not two separate updates and you can’t get to one—there is only one.
There has been a high demand to identify what data is/will be wrong. Many administrators are trying to evaluate if they want to run the rebase tool or not. Here are some SQL queries that will help to determine that information:
-- On each content database (SPS 2003's default content database ends in _SITE) you
-- can run these commands to evaluate what state your data is in with respect to DST2007
-- Show webs that have not yet been rebased
SELECT FullUrl,Flags FROM Webs WHERE (Flags & 8192) = 0
-- Show webs that have been rebased
SELECT FullUrl,Flags FROM Webs WHERE (Flags & 8192) != 0
-- Find what timezones the Webs in this database are using
SELECT DISTINCT Webs.TimeZone from Webs
-- Run the below for each different TimeZone detected adjusting the query per the below note
-- Before rebasing, show data that needs to be adjusted (MARCH-APRIL)
--
-- NOTE: 08:00 UTC is 2AM CDT when DST starts (07:00 UTC is 2AM CDT the next day until the end of DST).
-- If the target webs are not set to CST, you will need to adjust this as appropriate for accuracy
-- NOTE: 11 is the TimeZone ID for CST. Choose the appropriate TimeZone ID from TIMEZONE.XML if you are not CST
-- NOTE: If the Web column is empty, that indicates it is the root of the site
SELECT Webs.FullUrl AS [Web], Lists.tp_Title AS [List Name], nvarchar1, datetime1, datetime2, datetime3, datetime4, datetime5, datetime6, datetime7, datetime8,
datetime9, datetime10, datetime11, datetime12, datetime13, datetime14, datetime15, datetime16
FROM Webs
INNER JOIN Lists
ON Webs.[Id] = Lists.tp_WebId
INNER JOIN UserData
ON Lists.tp_ID = UserData.tp_ListId
WHERE
(Webs.TimeZone = 11)
AND (((datetime1 IS NOT NULL) AND (datetime1 >= '2007-03-11 08:00' AND datetime1 < '2007-04-01 08:00'))
OR ((datetime2 IS NOT NULL) AND (datetime2 >= '2007-03-11 08:00' AND datetime2 < '2007-04-01 08:00'))
OR ((datetime3 IS NOT NULL) AND (datetime3 >= '2007-03-11 08:00' AND datetime3 < '2007-04-01 08:00'))
OR ((datetime4 IS NOT NULL) AND (datetime4 >= '2007-03-11 08:00' AND datetime4 < '2007-04-01 08:00'))
OR ((datetime5 IS NOT NULL) AND (datetime5 >= '2007-03-11 08:00' AND datetime5 < '2007-04-01 08:00'))
OR ((datetime6 IS NOT NULL) AND (datetime6 >= '2007-03-11 08:00' AND datetime6 < '2007-04-01 08:00'))
OR ((datetime7 IS NOT NULL) AND (datetime7 >= '2007-03-11 08:00' AND datetime7 < '2007-04-01 08:00'))
OR ((datetime8 IS NOT NULL) AND (datetime8 >= '2007-03-11 08:00' AND datetime8 < '2007-04-01 08:00'))
OR ((datetime9 IS NOT NULL) AND (datetime9 >= '2007-03-11 08:00' AND datetime9 < '2007-04-01 08:00'))
OR ((datetime10 IS NOT NULL) AND (datetime10 >= '2007-03-11 08:00' AND datetime10 < '2007-04-01 08:00'))
OR ((datetime11 IS NOT NULL) AND (datetime11 >= '2007-03-11 08:00' AND datetime11 < '2007-04-01 08:00'))
OR ((datetime12 IS NOT NULL) AND (datetime12 >= '2007-03-11 08:00' AND datetime12 < '2007-04-01 08:00'))
OR ((datetime13 IS NOT NULL) AND (datetime13 >= '2007-03-11 08:00' AND datetime13 < '2007-04-01 08:00'))
OR ((datetime14 IS NOT NULL) AND (datetime14 >= '2007-03-11 08:00' AND datetime14 < '2007-04-01 08:00'))
OR ((datetime15 IS NOT NULL) AND (datetime15 >= '2007-03-11 08:00' AND datetime15 < '2007-04-01 08:00'))
OR ((datetime16 IS NOT NULL) AND (datetime16 >= '2007-03-11 08:00' AND datetime16 < '2007-04-01 08:00')))
-- Before rebasing, show data that needs to be adjusted (OCTOBER-NOVEMBER)
--
-- NOTE: 08:00 UTC is 2AM CDT when DST starts (07:00 UTC is 2AM CDT the next day until the end of DST).
-- If the target webs are not set to CST, you will need to adjust this as appropriate for accuracy
-- NOTE: 11 is the TimeZone ID for CST. Choose the appropriate TimeZone ID from TIMEZONE.XML if you are not CST
-- NOTE: If the Web column is empty, that indicates it is the root of the site
SELECT Webs.FullUrl AS [Web], Lists.tp_Title AS [List Name], nvarchar1, datetime1, datetime2, datetime3, datetime4, datetime5, datetime6, datetime7, datetime8,
datetime9, datetime10, datetime11, datetime12, datetime13, datetime14, datetime15, datetime16
FROM Webs
INNER JOIN Lists
ON Webs.[Id] = Lists.tp_WebId
INNER JOIN UserData
ON Lists.tp_ID = UserData.tp_ListId
WHERE
(Webs.TimeZone = 11)
AND (((datetime1 IS NOT NULL) AND (datetime1 >= '2007-10-28 08:00' AND datetime1 < '2007-11-04 08:00'))
OR ((datetime2 IS NOT NULL) AND (datetime2 >= '2007-10-28 08:00' AND datetime2 < '2007-11-04 08:00'))
OR ((datetime3 IS NOT NULL) AND (datetime3 >= '2007-10-28 08:00' AND datetime3 < '2007-11-04 08:00'))
OR ((datetime4 IS NOT NULL) AND (datetime4 >= '2007-10-28 08:00' AND datetime4 < '2007-11-04 08:00'))
OR ((datetime5 IS NOT NULL) AND (datetime5 >= '2007-10-28 08:00' AND datetime5 < '2007-11-04 08:00'))
OR ((datetime6 IS NOT NULL) AND (datetime6 >= '2007-10-28 08:00' AND datetime6 < '2007-11-04 08:00'))
OR ((datetime7 IS NOT NULL) AND (datetime7 >= '2007-10-28 08:00' AND datetime7 < '2007-11-04 08:00'))
OR ((datetime8 IS NOT NULL) AND (datetime8 >= '2007-10-28 08:00' AND datetime8 < '2007-11-04 08:00'))
OR ((datetime9 IS NOT NULL) AND (datetime9 >= '2007-10-28 08:00' AND datetime9 < '2007-11-04 08:00'))
OR ((datetime10 IS NOT NULL) AND (datetime10 >= '2007-10-28 08:00' AND datetime10 < '2007-11-04 08:00'))
OR ((datetime11 IS NOT NULL) AND (datetime11 >= '2007-10-28 08:00' AND datetime11 < '2007-11-04 08:00'))
OR ((datetime12 IS NOT NULL) AND (datetime12 >= '2007-10-28 08:00' AND datetime12 < '2007-11-04 08:00'))
OR ((datetime13 IS NOT NULL) AND (datetime13 >= '2007-10-28 08:00' AND datetime13 < '2007-11-04 08:00'))
OR ((datetime14 IS NOT NULL) AND (datetime14 >= '2007-10-28 08:00' AND datetime14 < '2007-11-04 08:00'))
OR ((datetime15 IS NOT NULL) AND (datetime15 >= '2007-10-28 08:00' AND datetime15 < '2007-11-04 08:00'))
OR ((datetime16 IS NOT NULL) AND (datetime16 >= '2007-10-28 08:00' AND datetime16 < '2007-11-04 08:00')))
If you are looking for information on other products, utilize these resources:
Planning wizard - http://www.microsoft.com/dst2007
DST2007 BLOG - http://blogs.technet.com/dst2007/
PRODUCT BREAKDOWN:
==================
SPS 2001 – requires the OS be patched (931836 for W2K3)
WSS 2003 SP1
1. 924881 and later will not apply—you will get a warning/popup.
2. Update to SP2 and apply 933738 update and run stsadm –o tzmove per 933738.
3. Don’t update to SP2 and follow 933853 to ensure that new data is created correctly. Existing data will be wrong and can be manually modified.
4. Do nothing and inform users the time periods that will be an hour off and in which direction.
WSS 2003 SP2
1. Apply 933738 update and run stsadm –o tzmove.
2. Only follow 933853 to ensure that new data is created correctly. Existing data will be wrong and can be manually modified.
3. Do nothing and inform users the time periods that will be an hour off and in which direction.
SPS 2003 SP1
1. Follow WSS 2003 Instructions that match your WSS SP level (Servers could be either SP1 or SP2). Microsoft recommends that servers be updated to SPS 2003 SP2 if WSS 2003 is at SP2.
SPS 2003 SP2
1. Follow WSS 2003 SP2 instructions.
WSSv3
1. Clean Install:
a. No action required. WSSv3 is compliant out of the box.
b. WSSv3 also maintains history of prior DST time periods (see C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG\timezone.xml). Because of this, any beta participant that created data in the DST delta during beta and upgraded to RTM should also need no action.
2. Upgrade:
a. If you have not upgraded yet, you should follow the WSS2003 SP2 instructions and ensure you use stsadm –o tzmove per 933738 before upgrading.
b. If you have already upgraded, any data created after upgrade in the DST delta will be correct. Any existing data in the delta may need to be manually adjusted. See the upgrade section of 933738 for more information.
c. If you have already upgraded but you did a gradual upgrade—we do update the [C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\CONFIG\timezone.xml] file to be DST2007-compliant as a part of upgrade, so any data added to a non-migrated v2 site running on a v3 server will be properly created. Data that existed prior to the upgrade is at the same risk covered in the upgrade section of 933738.
MOSS
1. Follow WSSv3 instructions
STSADM INFO:
===========
The one remaining risk with tzmove is having data created on the same day as when the timezone.xml is made DST2007-compliant. If this occurs, it is critical to know if the new data was created before or after the timezone.xml change. If data was only created before, then you could move the date forward one day (from 3-08 to 3-09 if you updated on 3-08) and you would successfully update everything done before the timezone.xml update. If the data was only created after, then you should use the timezone.xml update day as the parameter because you don’t want to rebase the items created on that day.
FAQ:
===
Q: Why does 933738 refer to manually updated timezone.xml files in the install requirements section? Under what circumstances would someone have manually updated their timezone.xml?
A: There are many areas in the world where the time zone changes from year to year. As such, servers may have had their timezone.xml edited per 888253. If the timezone.xml has been manually updated to be DST2007-compliant, it requires special treatment. This is described in 933738. We also provided 933853 to help guide customers who want to do this process manually so that they can do it properly.
Q: Explain modified date.
A: When you modify the timezone.xml to be DST2007 compliant (via an update or manually), every time you create a new item after that using a date during the DST2007 deltas (3-11 to 4-1 and 10-28 to 11-4), it will be correctly created. Any item that was created in the DST2007 Delta windows before the timezone.xml was updated will be an hour off. The stsadm -o tzmove was created to address the items that will be an hour off. This is why knowing when the timezone.xml was updated for DST is so important.
Q: I already applied 924881, do I need to apply 933738?
A: Yes, we recommend you install 933738 or later, because 933738 was when the tzmove operation was first added to stsadm and it is recommended that you run the tzmove operation.
Q: I have not applied 924881, do I need to before I apply 933738?
A: No, you do not need to apply 924881 because all WSS hotfixes are cumulative. Any update that was in a prior hotfix is included in 933738 (including the timezone.xml update that was in 924881).
Q: What if you can't apply SP2?
A: Updates to SP1 are no longer supported. If you absolutely cannot upgrade to SP2, then the only thing you can do is to follow 9333853 and manually modify your timezone.xml so that new appointments are correct. You then could manually adjust appointments within the 3-11 to 4-1 and 10-28 to 11-4 time periods so they are correct (the SQL queries above will help with this). Alternatively, you could ignore the scenario entirely and not update any file--but rather send email to all their users explained that their items will be an hour off between 3-11 to 4-1 and 10-28 to 11-4.
Q: If I am on WSS SP1 and SPS SP1 and I only apply WSS SP2 and then 933738, will it work?
A: Yes, this specific operation will work. However, Microsoft strongly recommends that you match their SPS service pack level with your WSS service pack level.
EXAMPLE SCENARIOS:
================
Joe has appointments for the week of 3-18-2007 in his Events list. These were created at some point in 2006. Joe applied hotfix 924881 on 2-14-2007. On 3-1-2007 Joe made appointments for the week of 3-11-2007 in his Events list. If Joe runs the stsadm -o tzmove command with the date of 2-14-2007, then all of the appointments between 3-11-2007 and 4-1-2007 will be correct. The items that would actually change would be any item between 3-11-2007 and 4-1-2007 that was created before 2-14-2007. In this example, that means that the appointments for the week of 3-18 are the only ones that are adjusted because since the ones for the week of 3-11 were made after the timezone.xml was updated for DST--those were correctly stored.
If instead of using 2-14-2007 as the parameter for stsadm, lets say Joe decided to use 3-09-2007. The appointments in the week of 3-18 will be correctly adjusted, but the appointments in the week of 3-11 will be an hour off because they should not have been modified. This is because the timezone.xml was already updated when he created the 3-11 appointments, so they were already stored properly. When he gave the wrong date (3-09) to stsadm, it adjusted everything created before 3-09, which included the 3-01 items that were already correct.
Lets go back to the scenario where Joe properly used the date of 2-14, which is when he applied the updated timezone.xml hotfix. On 3-09, Joe runs the stsadm command and properly provides 2-14 as the date value. All of the data is properly adjusted. On 3-10, Sue, who didn't realize Joe had already run the command runs the same command using 2-14 as the date value. Since when Joe ran the command on 3-09, stsadm had set a flag on each web as it processed it--when Sue ran it on 3-10, stsadm properly detected that the webs had already been adjusted and nothing was changed. Sue was surprised to find this, and when she inspected the Webs table of the content databases, she noted that the Flags column had a value of 8195 where before she happened to know it had a value of 3. She quickly did the math in her head and realized that when Joe ran the command successfully there was a bitwise addition of 0x2000 (8192) to the previous value of 0x3 (3). Out of raw curiosity, Sue ran the stsadm command again, but provided 3-10 as the date value. Since Joe had already successfully updated every web, no changes occurred to the appointments in the week of 3-11, even though they were passed over when Joe ran his command.
Roger ran the command in another farm and he found that the command did not complete successfully. He found that in the \Windows\Temp folder there was an stsadm.log file which showed which webs failed. He contacted Microsoft CSS for further assistance.
