Project: v8 Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 7 users
Status: Assigned
Owner:
Cc:
HW: ----
OS: ----
Priority: 3
Type: Bug



Sign in to add a comment
timezone offset and timezone string may become inconsistent if timezone changes in d8
Project Member Reported by yangguo@chromium.org, Aug 27 2013 Back to list
Consider this:

~/v8$ out/ia32.release/d8 
V8 version 3.21.4 (candidate) [console: dumb]
d8> var a = new Date(); var b = new Date();
undefined
d8> a
Tue Aug 27 2013 01:59:24 GMT-0700 (PDT)
d8> b
Tue Aug 27 2013 01:59:24 GMT-0700 (PDT)
d8> "change timezone"
"change timezone"
d8> b
Tue Aug 27 2013 01:59:24 GMT-0700 (PDT)    // timezone string for b is still being cached, hence "PDT"
d8> a
Tue Aug 27 2013 01:59:24 GMT-0700 (CEST)
d8> b
Tue Aug 27 2013 01:59:24 GMT-0700 (CEST)   // single element cache has been cleared.


We can see that
1) the timezone offset never changes even though the system timezone has been changed.
2) the timezone string changes once the system timezone has changed, but using a single element cache for the timezone string, this doesn't apply immediately.
3) the resulting date string is contradictory: GMT-0700 (CEST) is not a valid timezone.

Further more:

~/v8$ date
Tue Aug 27 11:01:35 CEST 2013
~/v8$ out/ia32.release/d8 
V8 version 3.21.4 (candidate) [console: dumb]
d8> var a = new Date();
undefined
d8> "change timezone"
"change timezone"
d8> a
Tue Aug 27 2013 02:01:48 GMT-0700 (PDT)
d8> "change timezone"
"change timezone"
d8> a
Tue Aug 27 2013 02:01:48 GMT-0700 (PDT)


We can observe that:
4) the timezone offset cache is set the first time we use it, after the timezone has changed.
5) the timezone offset cache is not reset anymore.


Browsing the code, I found that the DST cache has similar issues:
6) the DST offsets are cached for a certain period of time
7) we assume that the timezone does not change. If it does, our cached timezone offset does not change, but getting the DST offset from the system may return the offset from a different (currently set) timezone.


I admit that timezone changes are rare, but we should at least be consistent when it does happen. I think we have two options:
- poll timezone offset and timezone string every single time, without caching. This is expensive, since the timezone offset is needed almost every time a Date.prototype method is called.
- poll timezone offset and timezone string only once at start up. This way, timezone changes are not observed by V8, but at least V8 stays consistent. We would still have issues with DST offsets in combination with timezone changes though: if somebody changes his timezone from A to B, V8 would continue running on timezone A, but fetching DST offsets from the system would assume timezone B, which mixes things up. The solution could be a V8-specific DST library, but...
 
Comment 1 by mark@chromium.org, Aug 27 2013
Cc: mark@chromium.org
On at least some systems, it may be possible to arrange to be notified when the timezone offset changes.

Two options to investigate on Mac are NSSystemClockDidChangeNotification (Cocoa) and kNotifyTimeZoneChange (<notify.h>).

You could cache the timezone offset indefinitely until receiving such a notification.
Comment 2 by fukino@chromium.org, Oct 21 2014
Is this bug going to be fixed?
Chrome OS file manager have  issue chromium:379595 , which is waiting this issue fixed.
(The bug is marked P1 because traveling with chromebook is not too rare and wrong time keep displayed until reboot.)
Thanks!
Status: Fixed
I think r24499 is supposed to fix this. It has already been merged to M39 (V8 3.29.88.7) and M28 (V8 3.28.71.16). Please reopen if this has not been fixed properly.
Status: Assigned
Never mind.  Issue 3116  was the fixed one. This is unrelated. 
Comment 5 by u...@chromium.org, Oct 21 2014
Labels: -Priority-Medium Priority-Low
Summary: timezone offset and timezone string may become inconsistent if timezone changes in d8 (was: timezone offset and timezone string may become inconsistent if timezone changes.)
It is unfortunate that issue tracker doesn't show that chromium issue 406382 was merged into this issue. These are actually two separate issues.

This issue concerns only d8 shell. We don't have hooks in d8 that check for system timezone change and call v8::Date::DateTimeConfigurationChangeNotification. I am considering adding this code to d8 as low priority.

V8 embedders should notify V8 on timezone change as Mark mentioned in comment #1. All internal date caches in V8 are cleared on v8::Date::DateTimeConfigurationChangeNotification.

Five months ago Mark landed https://codereview.chromium.org/251613002 which sends timezone change notification to V8 on all platforms including ChromeOS. Maybe crbug.com/406382 is caused by a regression since then?

I am unmerging crbug.com/406382 from this issue.
Comment 6 by u...@chromium.org, Oct 21 2014
The test case work correctly in Linux Chrome 38:

> var a = new Date(); var b = new Date();
> a
Tue Oct 21 2014 01:04:06 GMT-0700 (PDT)
> b
Tue Oct 21 2014 01:04:06 GMT-0700 (PDT)

# timezone change PDT -> CEST

> a
Tue Oct 21 2014 10:04:06 GMT+0200 (CEST)
> b
> Tue Oct 21 2014 10:04:06 GMT+0200 (CEST)
Labels: Priority-3
Sign in to add a comment