115911 - Difference from GMT is cached and doesn't refresh when time zone changes

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

Spun off from Bug 115545.  See
http://lxr.mozilla.org/seamonkey/source/js/src/prmjtime.c

Mozilla reads the difference from GMT at launch time, and caches this value.  If
the user changes the time zone while Mozilla is running, this cached value will
be wrong.

Reproducible: Always
Steps to Reproduce:
1. Type "javascript:new Date()" into the address bar; note the current time and
current time zone (GMT-0x00).  Should match the system clock.
2. Open the Date & Time control panel and switch to a different time zone.  Note
the system clock changes.
3. Switch back to Mozilla, click in the address bar and press Enter to get the
time again.

Actual Results:  The time zone will be updated correctly (the GMT-0x00 part),
but the local time still reflects the old time zone.

Expected Results:  The local time should reflect the new time zone.

When switching Daylight Savings Time takes effect in the Spring, or ends in the
Fall, the same problem occurs with no action from the user required.

Comment 1

[Phil Schwartau]

Reassigning to Patrick, as with other JS Date bugs; cc'ing bug 115545 people.
Changing OS : Mac ---> All, since I see the same problem on WinNT.
I'm not sure how to change the timezone on Linux. Anyone know?


TIMEZONE
On WinNT, if I change my timezone while Mozilla (or the JS shell) is
running , such change is not reflected in my next call to new Date().
Same is true on Mac9.1. Can't try on Linux yet (see above). 


MONTH/DAY/TIME
What if we change month/day/time while Mozilla/JS shell is running?
WinNT: the change IS reflected in my next call to new Date() !!!
Linux: the change IS reflected in my next call to new Date() !!!
Mac9.1 the change is NOT reflected


I don't know if the MONTH/DAY/TIME issue can be fixed in the same
way as the TIMEZONE problem, but I wanted to mention the discrepancy -

Comment 2

[Andy Lyttle]

Changing platform back to Mac per comments in bug 115942.  See that bug for the
Windows side of this.

Comment 3

[Andy Lyttle]

In 1.1a on both Mac OS 9 and Mac OS X, this no longer happens.

New behavior is, when the timezone changes, JavaScript still uses the original
timezone.  Local time is correct for the original time zone.  This behavior is
sane, but may not be quite what the user wants (the user wants JavaScript-based
clocks to update).

Marking this fixed marking 115942 as a dupe of bug 127246 which now matches this
behavior, so go there if you're interested.

Comment 4

[Phil Schwartau]

Marking Verified -