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

VERIFIED FIXED

Status

()

Core
JavaScript Engine
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Andy Lyttle, Assigned: Patrick C. Beard)

Tracking

Trunk
PowerPC
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

17 years ago
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 -
Assignee: rogerl → beard
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Internal clock doesn't refresh when system wakes from sleep → JS Date() no longer accurate after system wakes from sleep
(Reporter)

Comment 2

17 years ago
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

17 years ago
NOTE: same problem occurs in the standalone JS shell on my Mac9.1
(Assignee)

Comment 4

17 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Comment 5

17 years ago
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.
OS: Mac System 8.5 → All
(Assignee)

Comment 6

17 years ago
Created attachment 62067 [details] [diff] [review]
Uses Mac OS sleep queue to recompute dstLocalBaseMicroseconds.

First attempt at a fix.
(Assignee)

Updated

17 years ago
Whiteboard: Needs review
(Assignee)

Comment 7

17 years ago
Created attachment 62068 [details] [diff] [review]
Put inititialization of didReadLocation back.

Second attempt.
Attachment #62067 - Attachment is obsolete: true

Comment 8

17 years ago
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
Attachment #62068 - Flags: review+

Comment 9

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

sr=sfraser
Attachment #62068 - Flags: superreview+

Comment 10

17 years ago
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.
(Reporter)

Comment 11

17 years ago
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

17 years ago
Yes, the DST info come from the location record as well
(Reporter)

Comment 13

17 years ago
Just out of curiousity, what was the problem in the IIsi that needed to be
worked around?  Do you remember?
(Assignee)

Comment 14

17 years ago
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?
(Assignee)

Comment 15

17 years ago
I'd like to get this checked in today. Let's open another bug to deal with the 
caching problems.
(Reporter)

Comment 16

17 years ago
Done.  Bug 115911: Difference from GMT is cached and doesn't refresh when time
zone changes
(Assignee)

Comment 17

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: Needs review

Comment 18

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

Comment 19

17 years ago
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?
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.
You need to log in before you can comment on or make changes to this bug.