From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (Win98; U) BuildID: 2000033112 if a Date object is created using new Date(year, month, date) the toGMTString() and toUTCString() methods yield the wrong Date (1 day ahead). Reproducible: Always Steps to Reproduce: call alert(new Date(1989,10,9,8).toGMTString()); on Mozilla/MacIntosh (or any Netscape/Mac). Actual Results: The alert shows November 10th. Expected Results: show November 9th. This bug has been around since Netscape 2!

Well, in my copy of Communicator 4.7, typing javascript:alert(new Date(1989,10,9,8).toGMTString()); yields November 9th. Could it be a problem with the time and date settings on your computer?

Have you tested it on MacIntosh? This is a Mac-only bug. My settings are okay, and Internet Explorer gives the correct Date. I could reproduce the bug on 2 different MacIntosh computers (with about 6 different versions of Netscape/Mozilla) and it was confirmed in de.comp.lang.javascript by other people.

Sorry, it's my time settings that got me. It yields 9th November for me; it should yield 8th November (I'm in Australia, +10 hours GMT). I concur, 24 hours too fast.

Confirmed in build 2000071420.

I am unable to confirm the bug on my Mac. I am running Mac OS9. When I double-click on the attachment above, the relevant output is: In Netscape Navigator 4.7: toString : Thu Nov 09 08:00:00 GMT-0700 (1989 toUTCString : Thu, 09 Nov 1989 15:00:00 GMT toGMTString : Thu, 09 Nov 1989 15:00:00 GMT In Mozilla Build ID 2000070511 toString : Thu Nov 09 08:00:00 GMT-0700 1989 toUTCString : Thu, 09 Nov 1989 15:00:00 GMT toGMTString : Thu, 09 Nov 1989 15:00:00 GMT Note: in NN4.7, the right parens seems to be missing from the toString() output. What do other people get when they open this attachment on their Macs?

the problem seems to be that the timezone is not correctly recognized. I am in Berlin, that is GMT+0100. This is also what e.g. IE/Mac tells me. But with Netscape getTimezoneOffset() yields 23 hours. So when I open your attachment with NN4.72 I get toString: Thu Nov 09 08:00:00 GMT-2300 1989 toUTCString: Fri, 10 Nov 1989 07:00:00 GMT toGMTString: Fri, 10 Nov 1989 07:00:00 GMT The wrong timezone-offset has consequences only when transforming dates to GMT, that's why I noticed it there. BTW: no single bracket at toString() in my case, as you can see...

Confirming bug; assigning to mccabe -

Wow, I'm amazed this has been a problem for so long! This code in prmjtime.c looks fishy to me: line 200: /* Mask off top eight bits of gmtDelta, sign extend lower three. */ if ((machineLocation.u.gmtDelta & 0x00800000) != 0) { gmtOffsetSeconds = (machineLocation.u.gmtDelta & 0x00FFFFFF) | 0xFFFFFFFFFF000000LL; JSLL_UI2L(gmtDelta,0); } else { gmtOffsetSeconds = (machineLocation.u.gmtDelta & 0x00FFFFFFUL); JSLL_UI2L(gmtDelta,PRMJ_DAY_SECONDS); } /* * Normalize time to be positive if you are behind GMT. gmtDelta will * always be positive. */ JSLL_SUB(gmtDelta,gmtDelta,gmtOffsetSeconds); ... this code dates from well before I took over the Date object, and the checkin comments are lost to the sands of time. I'm not sure why it was normalized to be positive. It'll take me a bit to learn what's going on here. Any Mac developers in the house?

CCing mac-knowing js developers. I'd like to get rid of the JSLL_SUB line, or otherwise make the GMT offset come out on the right side of 0. I'm not sure what's going on with the bitmasks, though - anyone have documentation for these bits?

Patrick has graciously volunteered to look at this.

One Mac-specific problem is that PRMJ_DSTOffset() doesn't take the passed-in time into account to compute the DST offset. This would explain a 1 hour discrepancy between different times of year and asking the question. The 24 hour off problem seems to result from the strange way that PRMJ_LocalGMTDifference() "normalizes" the result depending on whether the GMT offset is negative or positive. BTW, the reason for the masking is that only the lower 24-bits of machineLocation.u.gmtDelta are significant. A simpler way to do the sign extension is to write ((machineLocation.u.gmtDelta << 8) >> 8). I don't understand why the returned value is always a non-negative value between 0 and (24 * 3600). This certainly doesn't take the international date line into account. I don't think the problem is localized to just PRMJ_LocalGMTDifference(), but is more widespread. The best overall solution would be to upgrade all of this code to use the new <UTCUtils.> routines, which can be used to convert an arbitrary local date/time to universal coordinated time (AKA GMT). These routines don't provide a way to back out just the DST offset or GMT offset, but can do appropriate conversions. Using these routines, I'd say the JavaScript date object should always represent dates as GMT, and then do a conversion to local time whenever converting to a string.

This is a tricky bug. We should fix it eventually, but it may require a substantial overhaul of the Mac date/time code.

Adding self to cc: list as I always seem to end up looking at time related bugs on the Mac :-)

To land this fix, we will have to add the Mac library UTCUtils to the project: mozilla/lib/mac/InterfaceLib/Interface.mcp I've done this in my build and verified the results.

This builds for me OK on linux. The only non-Mac change is to the signature of PRMJ_LocalGMTDifference, and the only use of that function is in a place in jsdate.c where the signature is implicit - and compatible with the change. r=mccabe, lets land it.

Fix checked in. Phil - this means we can stop ignoring all those Date testcase failures on the mac related to DST, because they should go away.

Verified fixed on my Mac(OS9), using Mozilla nightly 2000120817. After setting my system clock to Berlin and launching Mozilla, the output of the HTML testcase above is: toString : Thu Nov 09 08:00:00 GMT+0100 1989 toUTCString : Thu, 09 Nov 1989 07:00:00 GMT toGMTString : Thu, 09 Nov 1989 07:00:00 GMT This is correct!