7593 - JavaScript new Date objects off by +10 seconds

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[KerryGinn]

Dates are displayed 10 seconds ahead of the system clock:

<SCRIPT LANGUAGE="JavaScript">
	setInterval("top.status=(new Date()).toLocaleString()", 1000);
</SCRIPT>

Comment 1

[leger]

Updating QA Contact

Comment 2

[Mike McCabe]

Mmm.  Date.  At least it's not y2k.  Its d10s.

Setting status to assigned.

Comment 3

[cbegle]

updating QA contact and moving to the "JavaScript Engine" component.

Comment 4

[Mike McCabe]

Removing y2k from the status whiteboard.  I don't think being ten seconds off
qualifies.

Comment 5

[KerryGinn]

I do not see this problem in Gecko Milestone 7 for Mac PPC.  -- Kerry Ginn

Comment 6

[Mike McCabe]

Kerry -

Thanks for checking this.  Do you think it's safe to mark closed?

Comment 7

[KerryGinn]

I have been seeing (slightly undesirable?) behavior based upon the inherited
design of the Mac Mozilla browsers; it is probably well-known.  I wish to leave
it up to the current Mac designers if they want to improve the design or not.

Apparently, a value which translates the Mac's low memory global tick count to
time is fetched during browser initialization. Thereafter, the browser will not
recognize changes to the system clock.  I guess that there must be a ten second
synchronization discrepancy when programs are started which I was seeing.

I am strongly in favor of efficient execution and I'm sure that the current
Mozilla design is an efficient one; however, I wonder how well the current
Mozilla design keeps track of the current time if the browser is running when
daylight savings time begins and ends?

Comment 8

[Mike McCabe]

Kerry -

First, you should know that JavaScript has its own date and time initialization
code, separate from other date code in the browser.  If any date code has the
problem you observe, and a fix is found, it'll probably need to go in several
places.  (there's a small amount of redundant code between the browser and the
javascript engine, but it lets us maintain the engine separately, which we've
found to be a good thing.)

If you're interested in taking a look at the behavior of locking down the system
time, the relevant file is js/src/prmjtime.c, which provides the
platform-specific time-handling primitives used by js/src/jsdate.c, which is all
cross-platform code.  A relevant function (from my quick examination) is
MacintoshInitializeTime.

You should know that although this bug is currently assigned to me, it's not too
likely that I'm going to do any work on it.  I'm not really a macintosh person,
and the code works well enough now that I'd rather not touch it.  It seems
likely that other Macintosh programs have solved the same problem in better
ways. If you can cast any light on it (and provide a patch) please feel free.

Also cc'ing Wan-Teh in case anything has changed in the analogous NSPR code.

Comment 9

[leger]

Setting all Javacript bugs to rginda QA Contact.

Comment 10

[Mike McCabe]

[SPAM] Marking milestone 'future' as part of nsbeta3 triage.

Comment 11

[KerryGinn]

Isuggest closing/combining this bug to Bug#34724, which is getting more 
attention and probably has a correct explination in the comment from
[e-mail] 2000-06-16 14:23 

Comment 12

[Mike McCabe]

I don't see any connection between the two bugs.... however, I'd love to close
this one.  Are you still seeing the problem?

Comment 13

[KerryGinn]

Reccommend close.  My test script performed accurrately in M17, NN6b2, and a 

recent M18 nightly, using MacOS 8.6 on my G3/266.

Comment 14

[Mike McCabe]

Closing this bug. Thanks!