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

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.)

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?

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.

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.)

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?

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

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?