398485 - Date toLocaleString() clamps the year to -32767 .. 32767

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mats Palmgren (inactive)]

Spawned off from bug 327869 comment 18/19.

Date toLocaleString() clamps the year to -32767 .. 32767.

The root casue seems to be that 'tm_year' is a 16-bit field:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/prmjtime.h&rev=3.18&root=/cvsroot&mark=67#56
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/jsdate.c&rev=3.90&root=/cvsroot&mark=1625,1637-1638#1618

I think it would be better to at least return a correct date but with a
fallback format (toString()) rather than clamp the year.

Even more correct would be to make 'tm_year' 32-bit, but this also depends
on whether 'struct tm' has a 32-bit type for 'tm_year' (AFAICT it's an 'int'
on modern Linux, Windows, MacOSX platforms) and that strftime() handles all
the years for a valid Date (i.e. years in the range -271820..275760).
I tested that (with the patch in bug 327869) on Windows and Linux and 
that seems to be the case, so I suggest we remove the clamping in
new_explode() and make PRMJTime::tm_year be a JSInt32.
Patch coming up...

Comment 1

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 2

[Mike Schroepfer]

Comment on attachment 283480 [details] [diff] [review]
Patch rev. 1

Any concerns about regressions due to callers assuming the old behavior?

Comment 3

[Reed Loden [:reed]]

Checking in js/src/jsdate.c;
/cvsroot/mozilla/js/src/jsdate.c,v  <--  jsdate.c
new revision: 3.92; previous revision: 3.91
done
Checking in js/src/prmjtime.h;
/cvsroot/mozilla/js/src/prmjtime.h,v  <--  prmjtime.h
new revision: 3.19; previous revision: 3.18
done

Comment 4

[Bob Clary [:bc] (inactive)]

/cvsroot/mozilla/js/tests/ecma_3/Date/15.9.5.5-02.js,v  <--  15.9.5.5-02.js
initial revision: 1.1

Comment 5

[Bob Clary [:bc] (inactive)]

verified fixed 1.9.0 linux|mac|win