Comment 5 for bug 838525

Here is another wrinkle to be aware of. It doesn't change the fact that we should simply be using a DATE type, but it might affect some other areas where dates and timezones enter in. Try this code on a page with dojo loaded (you can try it easily here - http://dojo-sandbox.net/ ):

dojo.require("dojo.date.stamp");
alert(dojo.date.stamp.toISOString(new Date(2011,2,1)));
alert(dojo.date.stamp.toISOString(new Date(2011,2,21)));
alert(dojo.date.stamp.toISOString(new Date(1979,2,21)));

The three alerts I get (I am in EST/EDT) are:

2011-03-01T00:00:00-05:00
2011-03-21T00:00:00-04:00
1979-03-21T00:00:00-04:00

The first two cross the DST boundary, hence the change in timezone, and are correct. The last, however, is wrong. In 1979, DST did not start until the end of April, so it should read '1979-03-21T00:00:00-05:00'. toISOString() is incorrectly applying current DST rules to past dates. I have not looked into whether this is a dojo bug or a bug in the underlying Mozilla toISOString(), but I suspect the latter.

Postgres, on the other hand, handles the local timezone quirks correctly, and therefore "corrects" this incorrect data. If I set the 'dob' column to either of the top two, they store as entered, as they 'make sense' in my local context. If I try to set the third, Postgres recognizes that the given day and timezone combination would have never occurred historically at my location, and therefore needs adjustment. Of course, we end up with '1979-03-20 23:00:00-05' getting stored in the DB.

The takeaway here is that we cannot currently rely on toISOString to create locally correct strings for past dates. Thankfully, most of our day-to-day date needs are dealing with present and future dates.