Ok, it did used to work.  It's in how we convert the dates.  Right now the code expects a date.  But we know it should be a date, so we'll try to convert it.  It has been submitted as bug 95482.  This may or may not make it into the upcoming Service Release.

-Dave

Hi Rob,

Actually the intent of the bug fix was to solve an issue when the computer and server were in different time zones.  By passing the dates as strings, it is whatever the date is regardless of the timezone.  Day light saving and timezones won't adjust the date by hours or anything now. 
As for the issue you have where that code used to work, I will investigate it.  I'll let you know if a bug ends up being submitted on it.

-Dave 

Question...  I notice that when converting the string to a javascript Date object, it is passing the time zone with the date.

What happens if the user's machine is in a different time zone with the server?  What will be saved to the database? 

My intention is to work with whole dates (time is irrelevant). 

By the way, this update broke some of my CSOM code.  I don't know if this particular behavior change was intended.

I am using CSOM to add rows to the WebDataGrid.  Before, I could pass strings to the new row array, and that worked fine.  The WebDataGrid would handle them as dates.  Now, the server throws an error if I try to pass in a string.  To fix it, I have to turn all strings into proper Javascript Date objects.

This now throws a server error, where it didn't before: 

    var newrow = [
                     '11/12/2011'
                  ];
    rows.add(newrow);

This works:

    var newrow = [
                    new Date( '11/12/2011')
                  ];
    rows.add(newrow);

I just want to make sure that the css files won't fail to load for lack of being in the 2090 folder in the CDN.  If the client won't look for them in the 2090 folder, then we're probably ok.