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

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

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)

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

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.

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.

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.

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}

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

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?

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

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? :-)

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

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.

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

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

I'm caught similar issue: > new Date('2015-10-23T00:00:00+06:00').toLocaleString() > result: "23.10.2015, 0:00:00" (correct) but > new Date('2015-10-23T00:00:00+06:00').getHours() > result: 1 (wrong, should be 0) Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

This should be fixed in Firefox 63 (bug 1346211) which is about to be released next week.

Dup'ing forward to bug 1346211 which should have fixed this problem. Please reopen if the issue is still present. Thanks!