1478666 - getHour() returns incorrect value after timezone update

Status: RESOLVED DUPLICATE of bug 1348916

(Core :: JavaScript: Standard Library, defect, P3)

Description

[Cole Thorsen]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce:

1. Open the developer console and run:
(new Date()).toLocaleTimeString('en-us',{timeZoneName:'short'});
(new Date()).getHours();

2. Change the computer's timezone to a different timezone.

3. Navigate to a different page.

4. Run the same commands:
(new Date()).toLocaleTimeString('en-us',{timeZoneName:'short'});
(new Date()).getHours();

5. Change back to the original timezone

6. Navigate to a different page.

7. Run the same commands:
(new Date()).toLocaleTimeString('en-us',{timeZoneName:'short'});
(new Date()).getHours();


Actual results:

Normal timezone since the last restart of firefox (EDT):
"10:06:38 AM EDT"
10

Changed to PDT:
"7:07:10 AM PDT"
14

Change back to EDT:
"10:07:46 AM EDT"
14

(note the times change slightly due to the time it took to follow the steps)

Closing and re-opening firefox will solve this problem.


Expected results:

Normal timezone since the last restart of firefox (EDT):
"10:06:38 AM EDT"
10

Changed to PDT:
"7:07:10 AM PDT"
7

Change back to EDT:
"10:07:46 AM EDT"
10

(these are the results that Google Chrome Returns)

Comment 1

[Cole Thorsen]

I should note this is happening on OSX 10.13.5, not sure about windows or linux

Comment 2

[Cole Thorsen]

So basically its returning UTC for getHours instead of the local hours.

Comment 3

[Jason Orendorff [:jorendorff]]

The behavior has changed since this was filed. Now a time zone change doesn't seem to affect Firefox at all. Observed results: the same output three times. Same in the shell.

The Resync call here is skipped because timeZone_ isn't null anymore.

Anba, how are time zone updates intended to work?

Comment 4

[André Bargull [:anba]]

timeZone_ is reset in js::DateTimeInfo::internalUpdateTimeZoneAdjustment when the time zone offset changed or an explicit reset was requested. That function is called from js::ResetTimeZoneInternal which in turn is called when a new Realm is created. This is our behaviour since bug 796523. And then there's also bug 1343826 to request adding an observer service to Gecko to track system time zone changes. (bug 1343826 is a thing which I think should be implemented in Gecko instead of SpiderMonkey, because the frontend will also need this functionality to reset cached Intl.DateTimeFormat instances and the DOM/HTML component will need it to implement https://github.com/whatwg/html/pull/3047.)

Comment 5

[André Bargull [:anba]]

Let's dup this over to bug 1348916.