In the US, most states have a time period from about March to November where we actually change our Time Zone. Normally the Eastern part of the United States is in the Eastern Standard Time zone which is -5 hours from GMT. However, during the Spring and Summer, we switch to Eastern Daylight Savings Time which is -4 hours from GMT. This switch takes place on a Saturday night at 2:00 AM.
Because of this switch in Time Zone, a scheduled build may not run when you expect it to. Let me explain how we tried to accommodate for this. The scheduled time is stored in the database in the Server’s local time but the server always returns the time in GMT (or Universal Time). We store the time as local time on the server so that when the Time Zone is changed on the server you get back the right time. I better show you an example:
You set up your build to run every night at 1:00 AM. You originally set it up in January from a client on the east coast (that’s EST). Your server that is also on the east coast gets the value in GMT from the client which turns out to be 6:00 AM GMT. In March the Time Zone for the Eastern United States switched from EST to EDS (daylight savings time). Now in April when are your builds running? 6:00 AM GMT is actually 2:00 AM in EDS. But thankfully the time was not stored in GMT in the database. Since the time was stored as 1:00 AM local time, it is still 1:00 AM local time. When the scheduler requests the time from the server the time is returned as 5:00 AM GMT which is 1:00 AM EDS. And of course when EDS ends and we are back in EST, the same trick keeps our builds running at 1:00 AM.
If you really paid close attention to that example and got everything I was trying to convey, you probably noticed the Gotcha! As long as your server and clients are in the same timezone, you should never see any problems. As you change the time zones between clients and the server, you may notice some interesting side affects. For instance, if your server is in the pacific time zone, then it doesn’t change to daylight savings time until 3 hours later than you. So, you might have one or two builds a year that don’t start when you expect them to. And if your server is in a time zone that doesn’t switch to daylight savings time at all, but you are in a timezone that does, your builds will run an hour later in the Spring and Summer.
Unfortunately, when DST ended in November, we discovered a bug in the Visual Studio Build UI. When it converts from the UTC time on the server to the local time it does it as if it was the first day of the week (that’s Sunday). If your build is scheduled to run between 12:00 am and 2:00am, the UI will show it one hour earlier the week that DST ends and one hour later the week that DST starts. The builds will still start on time, but the UI shows it incorrectly. After that one week everything is good, but don’t try to change the scheduled time during that week either. It won’t get the time you expect because of the messed up conversion. Sorry for the bug, its all my fault 🙁
This Bug is fixed by service pack 1 of VSTS 2008. The service pack should be released before we have another DST change in the Fall.