Windows Azure Scheduler [part 2]

Yesterday, I posted about time zone issues with the new Windows Azure Scheduler.   Shortly after, I noticed a couple of additional issues that aren't time zone related at all.

There is a section of the documentation that describes recurrence patterns:

"recurrence": // optional
 {
 "frequency": "week", // can be "year" "month" "day" "week" "minute"
 "interval": 1, // optional, how often to fire (default to 1)
 "schedule": // optional (advanced scheduling specifics)
 {
 "days": ["monday", "wednesday", "friday"],
 "hours": [10, 22] 
 },
 "count": 10, // optional (default to recur infinitely)
 "endTime": "2012-11-04", // optional (default to recur infinitely)
 },

Do you see the problem?   It has to do with the frequency field.   Minutes are fine, and so are day and week (other than the DST issue I described in the other post).  But I am surprised to see month and year in there without some other options to qualify its behavior.

The problem is that "a month" is not a distinct unit of time.  Months have different lengths, either 28, 29, 30, or 31 days.  So what happens if you schedule an item to start on Jan 31 2014 and recur monthly?  There is no February 31st, so does that mean that the task doesn't run?  Or does it mean you run it on the 28th? Or maybe you run it on March 3rd, since that's 31 days from the last time you ran it?  Or somewhere in between?  Without some way to qualify the behavior, scheduling a task to run monthly is always going to be ambiguous for dates near the end of the month.

Let's just say you decided to go with the first option and run it on February 28th.  What happens in March then? One month from February 28th is March 28th, which _does _exist.  Should it have run then?  Or maybe it should have run on March 31st, since we originally scheduled it for January 31st.  Again, we need a way to qualify that in the rules for the recurrence pattern.

So what about years then?  Well, do you remember the Azure leap year bug?  That happened because an SSL certificate was generated on February 29th 2012, for one year in advance - February 29th 2013 - which doesn't exist.   So what happens if you schedule a recurring task to run annually on February 29th?  You might be starting on a valid date, but does it produce an invalid date for the next year? Hopefully not, or the task will never run.  It should probably run on February 28th or March 1st, but again, we need a way to qualify that in the recurrence rules for the job.

I will say again that it's a good thing that this service is in _preview.  _It gives the developers working on it time to collect feedback such as mine, and incorporate that into the final product.  So, Microsoft, thank you for releasing this in preview so the kinks can be worked out.