Date() gives wrong timezone after time zone change kb2998527

NEW
Unassigned
(Needinfo from 2 people)

Status

()

Core
JavaScript: Standard Library
3 years ago
8 days ago

People

(Reporter: anton.starcev, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug, {site-compat})

unspecified
site-compat
Points:
---

Firefox Tracking Flags

(firefox32 wontfix, firefox33 wontfix, firefox34+ wontfix, firefox35+ wontfix, firefox36- affected, firefox37 affected)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

1. install windows update kb2998527 - http://support.microsoft.com/kb/2998527/en-us
2. in developer's console type: new Date('2014/01/01')


Actual results:

Date 2013-12-31T21:00:00.000Z


Expected results:

Date 2014-01-01T00:00:00.000Z
(Reporter)

Comment 1

3 years ago
Same bug was fixed in chrome https://code.google.com/p/chromium/issues/detail?id=417640

Updated

3 years ago
Component: Untriaged → Untriaged
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Duplicate of this bug: 1074821
So apparently all of Russia is going into permanent winter time as of sometime in October, or so says one of the comments on the Chrome issue.

Date is specced, AIUI, to pretend that the current timezone stuff is the same as it has always been, so that browsers don't need to have a full and complete history of all timezone decisions by all governments everywhere, etc. etc... so that's probably related. Don't know how much of our code is the same as Chrome; if this is an ICU issue maybe a simple uplift can fix this, or we'd need to temporarily port this or something?

Till, or Jeff, do you know who can drive this? It's probably too late for 33 unless the fix is very safe, but 34 should be doable... the stories from that chrome bug about duplicate decembers in calendars and so on are a little scary...

(per the dupe, this affects at least Europe/Moscow timezone, and per this bug, on Windows versions with the relevant kb update, although I imagine other OSes might soon issue similar updates? Not sure... - still setting OS to a randomly picked version of Windows until further notice, per comment #0)
Status: UNCONFIRMED → NEW
status-firefox32: --- → affected
status-firefox33: --- → affected
status-firefox34: --- → affected
status-firefox35: --- → affected
tracking-firefox34: --- → ?
Component: Untriaged → JavaScript: Standard Library
Ever confirmed: true
Flags: needinfo?(till)
Flags: needinfo?(jwalden+bmo)
Keywords: site-compat
OS: All → Windows 7
(Reporter)

Comment 4

3 years ago
Mac OS X version currently have same issue:
new Date('2014/01/01')
Date 2013-12-31T20:00:00.000Z
(In reply to anton.starcev from comment #4)
> Mac OS X version currently have same issue:
> new Date('2014/01/01')
> Date 2013-12-31T20:00:00.000Z

Thanks for clarifying. :-)
OS: Windows 7 → All
While the timezone change in Russia might or might not lead to complications (I honestly don't know), this as stated seems unrelated: I think it's a dupe of bug 1073533.

Anton, I guess you're in UTC+3, so your January 1st, 12am is in fact UTC's December 31st, 9pm. Which is exactly the time printed in the console.
Flags: needinfo?(till)
(Reporter)

Comment 7

3 years ago
Till, you are right (Mac OS X):
new Date('2014/01/01').toString()
"Wed Jan 01 2014 00:00:00 GMT+0400 (MSK)"

and Windows:
new Date('2014/01/01').toString()
"Wed Jan 01 2014 01:00:00 GMT+0400 (Russia TZ 2 Standard Time)"

But I got on Windows:
new Date(2014, 0, 1, 0, 0, 0, 0).getHours()
1

while Mac OS X version is OK and return 0:
new Date(2014, 0, 1, 0, 0, 0, 0).getHours()
0
> and Windows:
> new Date('2014/01/01').toString()
> "Wed Jan 01 2014 01:00:00 GMT+0400 (Russia TZ 2 Standard Time)"

Ah, so this part is interesting. You should always get 12am in your local timezone when not specifying a time of day, but you get 1am instead.

Unfortunately, I really don't know much about how all of this works and where the issue may be. I hope Waldo may, so let's wait for his response.
status-firefox32: affected → wontfix
tracking-firefox34: ? → +

Comment 9

3 years ago
I my Win7 installation (with specified update installed) I CAN'T SET LOCAL TIME to 2014-01-01 00:00:00. Then I trying to do so, system is saying this is an incorrect time cause of summer time in effect. 

It seems like MS decided to create a "fake" summer time at 2014-01-01 and drop it to winter time at October 26 (the day timezones change in Russia).

So, I think Firefox behaves a right way, just like OS says. It moves time a hour forward.

Chrome has another issue. 2014-01-01 00:00:00 becomes 2013-31-12 23:00:00 (moving a hour back) so we can see a duplicated decembers or something.

Intresting, what IE11 on my system can normally create 2014-01-01 00:00:00 as before update installed.
Waldo, any thoughts on this? We're tracking this bug for 34 so it'd be good to at least know what has to happen here.
I don't have immediate thoughts, no.  :-\

I know at one time we did something to compute DST offset, that assumed that the epoch was always a no-DST time.  But we stopped doing that awhile ago, and the new algorithm as I read it (if I'm remembering which it is correctly) has no dependence on any particular time being DST or not.  See UTCToLocalStandardOffsetSeconds in js/src/vm/DateTime.cpp.

It also doesn't hugely help that I did a west-east flight last night, and my alertness is not especially great right now.

(In reply to Till Schneidereit [:till] from comment #8)
> > and Windows:
> > new Date('2014/01/01').toString()
> > "Wed Jan 01 2014 01:00:00 GMT+0400 (Russia TZ 2 Standard Time)"
> 
> Ah, so this part is interesting. You should always get 12am in your local
> timezone when not specifying a time of day, but you get 1am instead.

I don't think this is actually true.  String parsing is almost entirely unspecified, so there's nothing that (as I recall, in my slightly sleep-fogged state) says the string specifies a local time, or a local-sans-DST time, or a UTC time.

Comment 12

3 years ago
new Date(2013, 0, 1) => Date {Tue Jan 01 2013 00:00:00 GMT+0500}
new Date(2014, 0, 1) => Date {Tue Dec 31 2013 23:00:00 GMT+0500}
Duplicate of this bug: 1089592
(Reporter)

Comment 14

3 years ago
Looks like there is a solution for this issue:

"These errors are caused by localtime_s function in <time.h>. I attached a simple C++ program that demonstrates incorrect results of localtime_s. Chrome (and Firefox) uses localtime_s and therefore gets these test-cases wrong."
https://code.google.com/p/chromium/issues/detail?id=417640#c43


https://chromium.googlesource.com/v8/v8.git/+/2b26c7a144abeb891e30e9ebe2482e619c82b441%5E%21/#F0
(Reporter)

Comment 15

3 years ago
Forgot to add main point: "Windows: use SystemTimeToTzSpecificLocalTime instead of localtime_s."
(In reply to anton.starcev from comment #14)
> Looks like there is a solution for this issue:
> 
> "These errors are caused by localtime_s function in <time.h>. I attached a
> simple C++ program that demonstrates incorrect results of localtime_s.
> Chrome (and Firefox) uses localtime_s and therefore gets these test-cases
> wrong."
> https://code.google.com/p/chromium/issues/detail?id=417640#c43
> 
> 
> https://chromium.googlesource.com/v8/v8.git/+/
> 2b26c7a144abeb891e30e9ebe2482e619c82b441%5E%21/#F0

I don't see us using localtime_s anywhere in the relevant code - only in NSS, sqlite, crashreporter, and some sctp socket code. None of those are involved here.
Naveed - Can someone on your team take this for 34?
Flags: needinfo?(nihsanullah)
(In reply to :Gijs Kruitbosch from comment #16)
> I don't see us using localtime_s anywhere in the relevant code - only in
> NSS, sqlite, crashreporter, and some sctp socket code. None of those are
> involved here.

See ComputeLocalTime(time_t, struct tm*) in js/src/vm/DateTime.cpp (that code should probably use localtime_s instead of localtime, but that's a different issue...)
Naveed did a bunch of experiments that I interpret as basically confirming comment 9: this happens
because whatever timezone database localtime_s is using on Windows thinks that DST begins on
2014 January 1 in this timezone. It can't be true that summer time began in the middle of winter this
year, can it?

I guess we should switch over to the Win32 APIs as comment 15 says. This isn't a tiny change for us; looks like V8 was using a mix of POSIX and Win32, but already mostly Win32, so switching the last remaining thing to Win32 was just common sense for them.
Note that

    new Date(2014, 0, 1, 0, 0, 0, 0).getHours()
    1

is not by itself inconsistent. You can get a similarly bizarre result in my time zone, on Linux:

    js> new Date(2014, 2, 9, 2, 0, 0, 0).getHours()
    3

The input says 2AM and the output says 3AM, but they are two ways of writing exactly the same moment in time, since that is the moment of the jump to DST in my time zone.

So yes, there is definitely a bug in the behavior of localtime_s in this time zone, one we should consider working around, but the error is simply getting the starting date of DST wrong. Otherwise the behavior seems internally consistent.
Duplicate of this bug: 1093894
Duplicate of this bug: 1097223
Duplicate of this bug: 1098140
Note that this also affects dates in the future, the last dupe I duped lists 2020-01-01, for example.

Jason/Jeff: I hate to be "that guy", but, can this be prioritized? :-)
Flags: needinfo?(jorendorff)
(In reply to :Gijs Kruitbosch from comment #24)
> Jason/Jeff: I hate to be "that guy", but, can this be prioritized? :-)

FWIW, I like to see others stepping up to be "that guy".

We're at the end of the 34 beta cycle. As I haven't seen any real activity on this bug in a more than 2 weeks, I'm marking this as wontfix in 34. Like Gijs, I would like to see this prioritized to fix in 35 or 36 if possible.
status-firefox33: affected → wontfix
status-firefox34: affected → wontfix
status-firefox36: --- → affected
tracking-firefox35: --- → +
tracking-firefox36: --- → +
See Also: → bug 1106113
Duplicate of this bug: 1106530
Duplicate of this bug: 1107837
See Also: → bug 1107837
Wontfix for 35 as time has run out. Without an assignee or prioritization from the team, this is no longer a trackable issue. Please feel free to nominate the eventual fix for uplift and it can be considered based on risk v. reward at that time.
status-firefox35: affected → wontfix
status-firefox37: --- → affected
tracking-firefox36: + → -
Duplicate of this bug: 1109732

Comment 30

3 years ago
We've had an interesting manifestation of this bug in our application, which lead to a bug in YUI2.

https://github.com/yui/yui2/pull/15

Long story short:
1. Set your system timezone in Windows 7 to "(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)"
2. Set your system date to November or December 2014 (e.g. Dec 1st, 2014)
3. Evaluate `new Date((new Date(2014,11,1).setMonth(0))).getFullYear()` in console

Unexpectedly this returns 2013 and makes the YUI2 calendar break :)
Duplicate of this bug: 1227499

Comment 32

4 months ago
I have the same bug for the dates: 2040-04-01 (Date(2040,3,1)), 2043-04-01, 2054-04-01, 2065-04-01, 2068-04-01, 2071-04-01, 2082-04-01, 2093-04-01, 2096-04-01, 2099-04-01 and so on.
The bug is on Windows and Ubuntu.
(In reply to volodymyr.lomako from comment #32)
> I have the same bug for the dates: 2040-04-01 (Date(2040,3,1)), 2043-04-01,
> 2054-04-01, 2065-04-01, 2068-04-01, 2071-04-01, 2082-04-01, 2093-04-01,
> 2096-04-01, 2099-04-01 and so on.
> The bug is on Windows and Ubuntu.

We're currently using operating system methods to get various time zone informations. To workaround the Year 2038 problem [1] when calling these Posix-based OS methods, we're mapping years to "equivalent years", where equivalent means a year which starts on the same weekday and has the same number of days (365 or 366 for leap years). But if the chosen equivalent year uses different time zone rules, things will obviously break. So the current plan is to use a different library to compute time zone information (bug 1346211), which should allow us to compute the correct time for future dates.

[1] https://en.wikipedia.org/wiki/Year_2038_problem
Flags: needinfo?(nihsanullah)
Blocks: 285663
You need to log in before you can comment on or make changes to this bug.