Note that toDateString() is unambiguous about the year: js> (new Date('January 1, 1900')).toDateString() Mon Jan 01 1900 js> (new Date('January 1, 2000')).toDateString() Sat Jan 01 2000 But toLocaleDateString() is ambiguous on my Linux box : js> (new Date('January 1, 1900')).toLocaleDateString() 01/01/00 js> (new Date('January 1, 2000')).toLocaleDateString() 01/01/00 This leads to problems. For example, new Date() handles '01/01/00' this way: js> new Date('01/01/00') Mon Jan 01 00:00:00 GMT-0800 (PST) 1900 Therefore, constructs such as this produce a Y2K bug on Linux: js> new Date((new Date('January 1, 2000')).toLocaleDateString()) Mon Jan 01 00:00:00 GMT-0800 (PST) 1900 This is causing testcase ecma_3/Date/15.9.5.6.js to fail on Linux. On WinNT and Mac, there is no such problem with toLocaleDateString().

Seems reasonable to fix - usually with 'locale' stuff I leave it to the OS, but I expect that there's some way to ask the OS politely for a 4-digit year. I had to do that on windows with toLocaleString.

Roger, can you review? What does toLocaleDateString do on windows?

Looks fine, r=rogerl. On Windows we use the same scheme as toLocaleString (only %#x instead of %#c) and the OS generates a full year format (so far as I've seen).

Fix checked in.

Marking fixed.

Verified on Linux - also checked WinNT and Mac.