Time off in Microsoft Search Server 2008 Express SP1 (Sharepoint Services 3.0)
We have a sharepoint farm with 1 DB server and 2 WFE servers. We as a company have unchecked the DST checkbox on all servers and computers in order to control our time manually with our domain controllers. We do this so we can make DST happen at a certain time as to not interfere with our production. Our sharepoint time is off on list entries and document entries for about half of the year by 1 hour. Recently we changed time again and I set our regional settings from central time (-6) to mountain time (-7) to save an hour (we have to go back an hour because DST pushes us forward an hour in sharepoint and throws everything off). But when I did that, something with a due date of 4/11/2010 would now display as 4/10/2010. Big problem. I think it is because in the background the date is actually stored with the time as 12:00:00 am and when I set the time back one hour the date changes because now it is 11pm on the previous day.
I have tried to edit the timezone.xml but the changes never take effect. Restart IIS, reboot, etc, the timezones are always the same.
I adjust the server clock times but the list item's time doesn't change accordingly.
Where does sharepoint get it's time? and how can I manually adjust it?
How can be released of the bonds of daylight savings and have sharepoint just base its time off of wherever it get its time from?
I have tried to edit the timezone.xml but the changes never take effect. Restart IIS, reboot, etc, the timezones are always the same.
I adjust the server clock times but the list item's time doesn't change accordingly.
Where does sharepoint get it's time? and how can I manually adjust it?
How can be released of the bonds of daylight savings and have sharepoint just base its time off of wherever it get its time from?
ASKER
The execs that control when manufacturing is shutdown or not don't want DST to happen until they are ready for it. We have boxes going on a conveyor that have a time stamp on each box label. They don't want the labels to jump ahead an hour.
To combat this issue IT has unchecked "Adjust for DST" on all our computers and domain controllers. Then the day DST changes we change the time on the DC's at 9am or 5am or whenever we are told to. This has created a problem with Sharepoint because the server doesn't have DST adjustment checkbox checked on the sharepoint server so we have to adjust the regional settings to Mountain time even though we are in central time. Things are all screwed up with the time stamps on our sharepoint lists because of this.
To combat this issue IT has unchecked "Adjust for DST" on all our computers and domain controllers. Then the day DST changes we change the time on the DC's at 9am or 5am or whenever we are told to. This has created a problem with Sharepoint because the server doesn't have DST adjustment checkbox checked on the sharepoint server so we have to adjust the regional settings to Mountain time even though we are in central time. Things are all screwed up with the time stamps on our sharepoint lists because of this.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Tedbilly, thats what I did, but Sharepoint does care about DST apart from the OS...
This is what I had to do. I had to change the timezone.xml file at c:\program files\common files\microsoft shared\web server extensions\12\config.
I modified the central time zone to act just like arizona (who doesn't observe DST). After that I set all regional settings to Central. Now moving forward we don't have to worry about this issue because Sharepoint DST will never change.
OK that isn't a great solution. Do you realize changes to that file can be wiped out if you apply updates or upgrades to the farm and in case of a disaster recovery the change is NOT backed up.
Using 'Central Admin' go to the 'Web Application General Settings' for each web application and change the default time zone. That will be retained properly in the settings.
You closed the question before giving me a chance to respond to your last comment.
Using 'Central Admin' go to the 'Web Application General Settings' for each web application and change the default time zone. That will be retained properly in the settings.
You closed the question before giving me a chance to respond to your last comment.
ASKER
Why isn't it a great solution? It works perfectly for our needs. We do not want sharepoint thinking that it needs to adjust for DST. We want to control that using the server time. Microsoft points out in this article how to safely change the Timezone file. http://support.microsoft.com/kb/888253
As far as the file getting wiped if you perform updates. Verify the file is in tact after an upgrade. Also, make sure it is part of your disaster recovery plan to disable DST for the central time zone.
If we uncheck the DST checkbox on our domain, and we have sharepoint's default timezone.xml active, we would have to set our timezone in Sharepoint to Mountain during DST (-7:00) and then put it back to Central when DST is over (-6:00). Now we don't have to worry about Sharepoint, just the domain time.
It is a great solution.
As far as the file getting wiped if you perform updates. Verify the file is in tact after an upgrade. Also, make sure it is part of your disaster recovery plan to disable DST for the central time zone.
If we uncheck the DST checkbox on our domain, and we have sharepoint's default timezone.xml active, we would have to set our timezone in Sharepoint to Mountain during DST (-7:00) and then put it back to Central when DST is over (-6:00). Now we don't have to worry about Sharepoint, just the domain time.
It is a great solution.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
"Using 'Central Admin' go to the 'Web Application General Settings' for each web application and change the default time zone. That will be retained properly in the settings."
You have a great idea in your comment above, but if I select Arizona in Central Admin then my time would still be off half the year. Since Arizona is GMT -7 and we are in the Central time zone, which is GMT -6, the time in SharePoint would only be correct during the spring and summer months. Then when DST ended we would have to go and change the setting back to GMT -6.
As of now, since I have modified the Central time zone (GMT -6) to not observe DST, the server time, which we adjust manually, would dictate what time SharePoint records events.
You have a great idea in your comment above, but if I select Arizona in Central Admin then my time would still be off half the year. Since Arizona is GMT -7 and we are in the Central time zone, which is GMT -6, the time in SharePoint would only be correct during the spring and summer months. Then when DST ended we would have to go and change the setting back to GMT -6.
As of now, since I have modified the Central time zone (GMT -6) to not observe DST, the server time, which we adjust manually, would dictate what time SharePoint records events.
This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.
Our company is global with employees in a wide multitude of time zones. Our farm is in a North American time zone and we've never had any trouble by simply leaving the settings alone to work as Microsoft designed it.