Windows Azure Scheduler
Microsoft announced today a new managed service for Windows Azure: The Windows Azure Scheduler. This is basically an enterprise job scheduler, such as Quartz.net, but operated as a simple managed web service.
Basically, you can set up a job that will run once or periodically, and it will either make a call to an HTTP endpoint of your choosing, or send a message on a Windows Azure Storage Queue. This is all explained reasonably well in the documentation.
Unfortunately, it seems that Microsoft hasn't fully learned their lessons from the last big date/time related fiasco on Windows Azure. Granted, that was an entirely different issue, but you would think that when building something like the new Scheduler service, that they would take a hard look at their date/time related code to make sure all bases were covered. Unfortunately, it took me all of 30 seconds of reading the documentation to realize a large glaring hole: It is completely lacking proper time zone support.
Now, if you read the docs carefully, you might be calling BS. After all, there's this little paragraph:
“startTime” is the start time and allows the caller to specify a time zone on the wire in ISO-8601 format.
The example field shown is like this:
"startTime": "2012-08-04T00:00Z"
This is indeed an ISO-8601 formatted timestamp, and I suppose they mean you might instead pass a string like this:
"startTime": "2012-08-04T00:00-07:00"
But in thinking this allows you to specify a time zone, Microsoft has made one of the most common mistakes you can make with time zones: A "time zone" is not the same thing as a "time zone offset". This format allows for an offset, not a time zone.
I see this misconception on almost a daily basis in Stack Overflow questions. So much that I've written an entire section in the timezone tag wiki titled "Time Zone != Offset", which I'm sure I've linked to a hundred or so posts by now.
Well it's a good thing this was announced on November 4th, because Daylight Saving Time ended in the US on November 3rd, and ended in Europe a week before that. But they certainly will need to deal with it soon, or there will be a lot of bug reports coming their way on March 9th, 2014 when DST starts again in the USA. Of course, there are many places around the world that are still on DST, or will start before then, so they could encounter this even sooner than that.
So what's the big deal then? Have you ever scheduled a daily task to run and then found it an hour off after a daylight saving time change? If live in an area that has DST and you have a simple alarm clock, then you probably have experienced this at least once in your life. You just can't scheduled a daily recurring task by UTC or a fixed time zone offset alone. You instead need the ability to say "8:00 AM Pacific Time". Preferable using the IANA time zone database, you would say "8:00 AM in the America/Los_Angeles time zone". This would avoid most DST issues.
However you still need to think about what happens if the daily task is scheduled right _at _ the moment of transition. If that time doesn't exist on that day, what do you do? What if the time exists twice? There's a lot to consider. I've written TWO posts on this topic recently, which you can view here and here.
Well, at least this is still in "preview" release, but please Microsoft, take a hard look at this problem. You're shooting yourself in the foot.
And call me if you need help! :)
See also: Windows Azure Scheduler [part 2]