115545 - JS Date() no longer accurate after system wakes from sleep

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Andy Lyttle]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112011

Apparently Mozilla keeps an internal clock, seperate from the system clock. 
When the system goes into Sleep mode, everything stops, including the internal
clock.  When the system wakes from Sleep, the system clock is still accurate,
but Mozilla's internal clock doesn't update.

Reproducible: Always
Steps to Reproduce:
1. Load http://www.webwizardry.net/~phroggy/time.shtml and note the browser time
2. Reload; notice the time updates as it should
3. Put the system to sleep, wait a minute, and wake up

Actual Results:  The browser time is about a minute behind what it should be

Expected Results:  The browser time should still match the system time (adjusted
for time zone of course)

The test page uses the Date() function in JavaScript to get what Mozilla thinks
the current time is, in GMT.  If it's off, check your time zone settings.

Is this bug limited to JavaScript, or does it affect things like cookie
expiration?  History logging?  I dunno what all is time-sensitive...

I've only tested this on Mac OS; is it a cross-platform bug?

Comment 1

[Phil Schwartau]

I'm seeing this too. If I set my Mac9.1 to sleep for a long time interval, 
then when I wake it up, JavaScript Date()'s are all retarded by that interval.
Just put your Mac to sleep for awhile, wake it up, and then do 
  
                      javascript: new Date() 

in the URL bar. You get a date that is off by the amount of the sleep.
Assigning this one to Patrick, who will know the answer to this right away.
Is it a custom setting in "Energy Saver" that is responsible for this?
I'm thinking of this one in particular:


Advanced Settings
(checkbox) "Preserve memory contents on sleep"


For some reason, I'm unable to check this box and test the theory myself.
It's unchecked and greyed out -

Comment 2

[Andy Lyttle]

The "Preserve memory contents" checkbox only works on certain newer Macs -
laptops in particular - and only works if Virtual Memory is on.  Basically what
it does is save the complete contents of RAM to the VM Storage file before
shutting down.  When the system wakes from sleep, the data is read from the VM
Storage file back into RAM.  While asleep with this option, the system doesn't
have to keep supplying power to the RAM, so you don't drain your laptop's
battery.  This only works if the BIOS supports it (so it can wake up), which is
why it only works on some Macs.

I'm pretty sure that has nothing whatsoever to do with this bug.

Comment 3

[Phil Schwartau]

NOTE: same problem occurs in the standalone JS shell on my Mac9.1

Comment 4

[Patrick C. Beard]

The problem is that we cache a Microseconds() relative time base when 
the JavaScript library is first initialized. When Macintosh hardware sleeps, 
this clock is suspended, hence the loss of time. The solution is to use the 
system sleep queue, so that when the powerbook  wakes up again, we 
get an opportunity to recompute the time base.

Comment 5

[Patrick C. Beard]

Changing OS to all, because this problem afflicts all versions of the Mac 
OS, including Mac OS X. Luckily, the same solution will work in all 
versions of Mac OS as well.

Comment 6

[Patrick C. Beard]

Attachment: Uses Mac OS sleep queue to recompute dstLocalBaseMicroseconds.

First attempt at a fix.

Comment 7

[Patrick C. Beard]

Attachment: Put inititialization of didReadLocation back.

Second attempt.

Comment 8

[Steve Dagley]

Comment on attachment 62068 [details] [diff] [review]
Put inititialization of didReadLocation back.

r=sdagley - looks like my fix in 4.x almost 5 years ago

Comment 9

[Simon Fraser [no longer active]]

Comment on attachment 62068 [details] [diff] [review]
Put inititialization of didReadLocation back.

sr=sfraser

Comment 10

[Steve Dagley]

It occurs to me that the need for MyReadLocation to cache the machine location 
record is long gone (IIRC it was a problem in the PRAM chip in the IIsi).  
Consider the user that leaves Mozilla running while travelling across time zones.  
They'll probably reset their location in the Date & Time CP but we'll miss the 
change since we inly read the location record once at app startup.

Comment 11

[Andy Lyttle]

If that's a problem, what about Daylight Savings Time?  If I'm in PST (GMT
-0800) and suddenly switch to PDT (GMT -0700) while using Mozilla, wouldn't that
throw off Mozilla's clock too?  This would happen with no action by the user at all.

Comment 12

[Steve Dagley]

Yes, the DST info come from the location record as well

Comment 13

[Andy Lyttle]

Just out of curiousity, what was the problem in the IIsi that needed to be
worked around?  Do you remember?

Comment 14

[Patrick C. Beard]

If you look closely, you'll see that PRMJ_LocalGMTDifference() is also 
doing some caching, of the local to GMT zone difference. We clearly need 
some way to invalidate this caching when the user's time zone has 
changed. PowerBook sleep is on reason to recheck these values, but 
crossing from daylight savings time to standard time and vice versa 
should also invalidate these cached values.

What kind of a performance hit might we take if we remove ALL of the 
caching that's going on in this file?

Comment 15

[Patrick C. Beard]

I'd like to get this checked in today. Let's open another bug to deal with the 
caching problems.

Comment 16

[Andy Lyttle]

Done.  Bug 115911: Difference from GMT is cached and doesn't refresh when time
zone changes

Comment 17

[Patrick C. Beard]

Fix checked in.

Comment 18

[Phil Schwartau]

Verified Fixed in standalone JS shell built on Mac9.1,
from JS source pulled at 2001-12-18 17:30 PST

Comment 19

[Phil Schwartau]

And Verified Fixed in the browser (trunk binary 20011219xx Mac9.1).

Question: do we want to get this fix in the 0.9.7 branch, too?
Or is it too risky?

Comment 20

[Brian 'netdragon' Bober]

On my IBM Thinkpad With MS Windows XP, I did hibernate, and this problem 
didn't occur. So it doesn't look cross-platform. Sorry I couldn't test it 
sooner.