Bug 4892

Summary: Date constructor has problems with months larger than 11
Product: WebKit Reporter: Ruairi Mc Comb <ruairi>
Component: JavaScriptCoreAssignee: Maciej Stachowiak <mjs>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, ggaren
Priority: P2    
Version: 312.x   
Hardware: Mac   
OS: OS X 10.3   
URL: http://ruairimccomb.com/safari/date.htm
Attachments:
Description Flags
Demonstration of the bug.
none
Patch to wrap month around inside Date constructor, and Date.UTC.
darin: review-
Layout test
none
Updated patch darin: review+

Description Ruairi Mc Comb 2005-09-08 13:27:17 PDT
When creating dates in the following manner:

new Date(year, month, date);

If the month is larger than 11, the date returned starts going random. 

I've tested the page with Firefox (1.0.6 OSX, 1.0.1 & 1.0.6 WinXP) and IE (WinXP 6.0.2900) and if the 
month is larger than 11 these browsers update the date accordingly (e.g. if month is 13, they add 1 
year and 2 months).
Comment 1 Ruairi Mc Comb 2005-09-08 13:29:02 PDT
Created attachment 3820 [details]
Demonstration of the bug.
Comment 2 Mark Rowe (bdash) 2005-09-11 01:13:52 PDT
Confirmed with WebKit 412.7 and ToT WebKit.  In the ECMA 262 spec, section 15.9.1.12 (the MakeDay 
operator) it mentions that the year should be set to year + floor(month / 12), and the month to month % 
12.  This logic is currently implemented in date_object.cpp's fillStructuresUsingDateArgs.  The Date 
constructor does not make use of this function, so the adjustment never takes place.  It looks that 
Date.UTC suffers from the same problem.
Comment 3 Mark Rowe (bdash) 2005-09-11 01:46:24 PDT
Created attachment 3858 [details]
Patch to wrap month around inside Date constructor, and Date.UTC.

I will add some layout tests shortly.
Comment 4 Mark Rowe (bdash) 2005-09-11 16:19:03 PDT
Created attachment 3866 [details]
Layout test

This layout test covers both the Date constructor and Date.UTC.
Comment 5 Darin Adler 2005-09-11 21:54:26 PDT
Comment on attachment 3858 [details]
Patch to wrap month around inside Date constructor, and Date.UTC.

This fix doesn't look right to me. I think handling things like this is part of
the job of the makeTime function, so we should fix that instead of doing this.
Comment 6 Mark Rowe (bdash) 2005-09-11 22:20:00 PDT
Created attachment 3868 [details]
Updated patch

This patch moves the existing month wrapping from inside
fillStructuresUsingDateArgs into makeTime so that it handles the Date
constructor and Date.UTC case.
Comment 7 Darin Adler 2005-09-11 22:25:50 PDT
Comment on attachment 3868 [details]
Updated patch

Looks great. One complaint: The comment mentions CFGregorianDate overflow, but
that's only one reason to adjust the year and do %= on the month. The other is
to work best with the year offset machinery, and it applies even on
non-Mac-OS-X.
Comment 8 Geoffrey Garen 2005-09-18 11:17:22 PDT
*** Bug 4782 has been marked as a duplicate of this bug. ***
Comment 9 Kevin Smith 2007-11-13 14:26:18 PST
Has this actually been released in the latest version of Safari 2.0.4?  Because I still have a problem with this code:

var test = new Date(this.VisibleDate.getFullYear(),this.VisibleDate.getMonth()+(this.MonthRows*this.MonthColumns);
Comment 10 Darin Adler 2007-11-13 14:35:19 PST
(In reply to comment #9)
> Has this actually been released in the latest version of Safari 2.0.4?

No. It's fixed for Safari 3.