488066 - adjust time and timezone would make JavaScript freeze and affect Date constructor

Status: RESOLVED DUPLICATE of bug 1348916

(Core :: JavaScript Engine, defect)

Description

[Su Weisi]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

the time in the firefox's 3.0.8 just have some bugs

  <script>
function updateTime(){
document.getElementById("a").innerHTML=new Date().toLocaleString();
}
setInterval(updateTime,500);
  </script>
  <div id="a"></div>



Reproducible: Always

Steps to Reproduce:
1.the test code is in the details, open it in the both ie and firefox
2.in the windows, open the time adjustment window, try to change the time and timezone to see the time in the browser
3.ie always shows the real time after you have adjusted the new local time and time zone. firefox do not show the time zone difference, and what is more, when you have change the time forward and back for 2 or 3 times, the javaScript just freeze, the time won't update anymore.
Actual Results:  
Look at the steps

Expected Results:  
the time is incorrect or freeze

no

Comment 1

[Ria Klaassen (not reading all bugmail)]

Regression range appears to be:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-02-17+11%3A00&maxdate=2006-02-17+22%3A00
(I only tested the time, not the time zone.)

Comment 2

[Ria Klaassen (not reading all bugmail)]

Attachment: reporter's testcase

Comment 3

[Su Weisi]

I have found further info on the related issue of the setInterval timer, let's add one button here
<input type="button" value="Restart" onclick="setInterval(updateTime,500)" />
Once you adjust the clock ahead, the timer would works, when you put the clock back, timer stop, click on the button restart the setInterval, but this have nothing to do with timeZone, the timeZone won't update till you refresh the page.

Could anybody try to fix this bug?

Comment 4

[Jason Orendorff [:jorendorff]]

I think there are two totally separate issues here.

1. setInterval.

Our setInterval/setTimeout timers depend on the system clock to keep time properly. If you set an interval to do something every 5 seconds, but for some reason your system clock is extremely slow and it takes a whole minute for the system clock to tick off 5 seconds, then the event will happen every minute instead.

Likewise if you open the Date/Time Settings and tinker with the system clock, you're also tinkering with programs like Firefox that depend on the clock.

I don't think this is a bug, but it's a plausible viewpoint that it *is* a bug if there are more appropriate platform-specific timer APIs than the ones we're currently using to drive setInterval and friends. Maybe someone who agrees with that will file a separate bug against the DOM.

2. Time zone changes.

When the global Date constructor is initialized, the JS engine makes a note of what time zone the system is in at the moment. (See js_InitDateClass in js/src/jsdate.cpp.)

It's a global variable (!) affecting all Date objects, process-wide. Since each page has its own Date global, the time zone is recalculated for each new page. And this affects all other pages too. Quirky.

If we want to pick up time zone changes reliably, we need to add a JSAPI function JS_UpdateTimeZone(rt), and Gecko needs to listen for some system event (WM_TIMECHANGE on Windows, maybe?) and call the new function.

Comment 5

[Jeff Walden [:Waldo]]

Why shouldn't it be the JS engine's responsibility to observe system time changes?

(I agree #1 is plausibly a bug, certainly a quality-of-implementation issue.)

Comment 6

[(mostly gone) XtC4UaLL [:xtc4uall]]

I can confirm this Issue against Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19 ID:2010031422, but it's WFM against Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110724 Firefox/8.0a1 ID:20110724030752

=> resolving WFM?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

I still see the original behavior on trunk. The time doesn't change after changing the time zone unless I refresh the testcase.

Comment 8

[Till Schneidereit [:till]]

Under OS X 10.6, today's Nightly doesn't freeze but only updates the displayed time on changing the time, not the time zone. I guess that means that the second issue from comment 2 hasn't been resolved, while the first one has.

Should the description and platform be changed accordingly?

Comment 9

[André Bargull [:anba]]

bug 1348916 also tracks missing updates when the host time zone changes and has newer info, so let's dup this to that bug.