If you go to docs.jquery.com and pull open the docs for the datepicker and navigate to the month of November in 2008. You will notice that November 2 occurs twice in a row. Navigate to 2009, November 1 occurs twice. In 2010, November 7 occurs twice. We are using jQuery’s datepicker internally, so we had several users notice this for 2008, causing a colleague and I to dig into this problem. Also of note, is the fact that we tried this in Firefox 3, IE 7, Opera 9, and Safari and all of them produced the exact same results. After tracing through the jQuery date picker code, we came upon a line in the source (this was where the script was looping over the dates in the month, creating the table cells for each):
printDate.setUTCDate(printDate.getUTCDate() + 1);
When Nov 2 2008 was run through this code as printDate, it returned Nov 2 the first time and Nov 3 the second. Moreover, if you removed the expression and ran
printDate.setUTCDate(3);
the result was the same: Nov 2. In Firebug, we tried manually running the code and got the exact same result. Now, we found that changing this line (and all like it) to
printDate.setDate(printDate.getDate() + 1);
That is, using the regular date functions instead of the UTC versions, solved the problem and it solved it in all browsers. So, that leaves us with the question of why this was caused in the first place. It was nothing special to 2008, as it occurred in every year. At any rate, this solved our problem. I intend to do some additional poking through ECMA 262 to see if I can find the root of the problem, but I’ve got other fires to put out. We did find at least one other guy who was having a similar problem back in 2007.
Addendum: We played with this some more. The ultimate problem likes in the fact that the codebase mixes the use of regular date functions and UTC functions. Uniforming it either way solves the problem. This almost, almost makes sense–but not really. I still want to spend some time with ECMA 262, a pad of paper, and a pen and see if I can figure out why this is true. Maybe someone who knows a little more than I do about the specifics of the JavaScript Date object implementation can shed some light on this.
In the USA, Daylight Savings Time ends on November 2 2008, November 1 2009, and November 7 2010. Local time is affected by DST in most time zones (-60 minutes in November), but UTC is never affected. With that in mind, it’s a horrible idea to mix local time and UTC in calculations.
@Dave – One of these days I will actually start remembering when DST is instead of just waiting for the magic day when people either remark about how nice an extra hour of sleep will be or lamenting the loss of one.
Thanks for filling in the missing link. I am surprised that the jQuery date picker made this mistake and it went on this long without being fixed–jQuery is getting to be pretty commonly used (and will be even more once Microsoft integrates it with some of their offerings).
The problem was that setDate(+1) worked in some situations and setUTCDate(+1) worked in others, depending on whether you were going into or out of daylight savings. The actual dates when this occurs differs depending on which time zone you’re in. JavaScript seems to take this change into account when adding a day and only adds 23 hours sometimes (and 25 hours other times) hence the duplicated date.
Would this also be why my Novemeber has only got 30 days?!! I’m in the UK.