Closed Bug 45590 Opened 24 years ago Closed 24 years ago

Date.toGMTString() is 24 hours fast

Categories

(Core :: JavaScript Engine, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: wo, Assigned: beard)

References

()

Details

Attachments

(2 files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 -
Assignee: rogerl → 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.
Assignee: mccabe → beard
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.
Status: NEW → ASSIGNED
This is a tricky bug. We should fix it eventually, but it may require a 
substantial overhaul of the Mac date/time code.
Target Milestone: --- → Future
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.
Depends on: 61577
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: