The same issue was reported in bug 543300.

Can some one on the V8 side take a look?

Issue 543300 has been merged into this issue.

+ hablich@ to help triage to the right owner.

Also see some user feedback on this in the release blog:
http://googlechromereleases.blogspot.com/2015/10/stable-channel-update.html
"I faced a problem about time zone in this version. The correct behavior is to obtain local time zone, but in my program, chrome automatically fetched the zero-time zone."

So this is interesting.  The citations I provided earlier are from ECMA-262 v 5.1  The relevant passage is in section 15.9.1.15 which reads:

> If the HH, mm, or ss fields are absent “00” is used as the value and the value of an absent sss field is 
> “000”. The value of an absent time zone offset is “Z”.

> http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15

However, in ECMA-262 v 6.0, the relevant section is 20.3.1.16, which now reads:

> If the HH, mm, or ss fields are absent "00" is used as the value and the value of an absent sss field is
> "000". If the time zone offset is absent, the date-time is interpreted as a local time.

> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-date-time-string-format

(... big thumbs up there, spec writers.  Thanks for the arbitrary but breaking change!)

So it appears that Chrome 45, FF and IE are consistent with v 5.1, while Chrome 46 is consistent with v 6.0.

As a web app creator, I would prefer consistency with the other browsers and therefore with v 5.1 to consistency with v 6.0, but I leave it to you all to decide on a course of action.

This changed in https://codereview.chromium.org/1229903004

I just tried 'new Date('2015-10-14').toString();' in Firefox 41 and 42 the result is '"Wed Oct 14 2015 02:00:00 GMT+0200 (CEST)"'. The original issue which implemented it (https://code.google.com/p/v8/issues/detail?id=4242) mentioned that FF is already supporting this. That is not the case.

Re #8:  FF returns different results depending on whether hh:mm:ss is present or not:

> new Date('2015-10-14').toString();
"Wed Oct 14 2015 02:00:00 GMT+0200 (CEST)"

> new Date('2015-10-14T00:00:00').toString();
"Wed Oct 14 2015 00:00:00 GMT+0200 (CEST)"

v8:4242 tested the latter case.

 Issue 539813  has been merged into this issue.

Firefox, Safari, and IE default to UTC when parsing 'YYYY-MM-DD'.

Firefox and IE default to local zone when parsing 'YYYY-MM-DDT00:00:00'.

To be consistent with the 'YYYY-MM-DD' case, we are going to revert the CL and work on fixing the spec.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/dd3f1ecf719afd21b4c695c776b4da2fb494ef92

commit dd3f1ecf719afd21b4c695c776b4da2fb494ef92
Author: ulan <ulan@chromium.org>
Date: Thu Oct 15 12:17:56 2015

Revert of Make dates default to the local timezone if none specified  (https://codereview.chromium.org/1229903004/)

Even though the change is ES6 spec compliant, we decided to revert
to be consistent with other browsers and work on fixing the spec.

Original issue's description:
> Make dates default to the local timezone if none specified
>
> In ES5, dates were supposed to default to UTC if no timezone was specified. However, this changed in ES6, which specified that dates should be in the local timezone if no timezone was specified. This CL updates our behavior to match that part of the ES6 spec.

> BUG= chromium:391730 ,  v8:4242 
> LOG=Y

> Committed: https://crrev.com/f06754a8e1d305a43560705f6c167d85d40e602d
> Cr-Commit-Position: refs/heads/master@{#29854}

BUG= chromium:543320 , chromium:539813 
LOG=NO

Review URL: https://codereview.chromium.org/1403153003

Cr-Commit-Position: refs/heads/master@{#31295}

[modify] http://crrev.com/dd3f1ecf719afd21b4c695c776b4da2fb494ef92/src/dateparser-inl.h
[modify] http://crrev.com/dd3f1ecf719afd21b4c695c776b4da2fb494ef92/src/dateparser.h
[modify] http://crrev.com/dd3f1ecf719afd21b4c695c776b4da2fb494ef92/test/mjsunit/date-parse.js
[modify] http://crrev.com/dd3f1ecf719afd21b4c695c776b4da2fb494ef92/test/mjsunit/date.js
[modify] http://crrev.com/dd3f1ecf719afd21b4c695c776b4da2fb494ef92/test/test262/test262.status

Spec bug filed: https://github.com/tc39/ecma262/issues/87

It was not a clean revert so Canary coverage is a must. The earliest point to merge this is IMO Monday. This should give us enough time to evaluate the impact.

See my comments in the spec bug.  
https://github.com/tc39/ecma262/issues/87

FF may not have yet implemented the change, but they have indeed stated in the MDN docs that the change is coming.

WRT: "This is breaking an app we have in production.  Dates are sent from server as YYYY-MM-DD. "

That's the problem then.  You're sending a date from your server without qualifying its time or time zone.  If it is indeed supposed to be interpreted as UTC, then your server should be sending YYYY-MM-DDZ, or preferably YYYY-MM-DDTHH:MM:SSZ.

If you indeed just meant a calendar date, as in a birth day or a particular whole day of the week, then sending YYYY-MM-DD is indeed correct, but expecting it to be interpreted as midnight on that date in UTC is not.  My birthday is 1976-08-27, not 1976-08-27T00:00:00Z.  I explained this recently in another context here:
http://stackoverflow.com/a/33130024/634824

The old ES5 behavior is wrong, and causes lots of confusion.  The new ES6 behavior is better.  Yes, it is a breaking change from the old bad behavior, but one IMHO should indeed be fixed.

For what it is worth, I am also seeing date-related timezone problems that are unique to v46 and do not appear on v45. In my case, I receive an ISO 8601 string from a commercial third-party vendor. It looks like this: 2015-10-03T00:28:05. It has a date and a time, but no explicit timezone mentioned. When I construct a Date object with this time, in Chrome 45 it interprets the timezone differently than in Chrome 46. This is also breaking a production app we have, but I am trying to work in some new logic to address this that will not cause differences in behavior between different versions of chrome and other browsers. Now I could request the vendor to explicitly provide a timezone, but their API is used widely and I suspect it will take a while to get a change from them. 

With the chrome 46 auto update, it happen to our production app. 

To clarify again: Chrome 46 was implementing a spec change in ES6, which now requires dates with no time zone to be interpreted as local time. Other browsers are expected to follow suit. The motivation for this spec change was to correctly implement ISO 8601, and in general, there are good reasons to prefer its behaviour.

However, as this is breaking some sites, we have rolled back the change for now (the patch should land in Chrome 46 soon), and will bring the issue up with the EcmaScript committee. I'm not sure what the committee will decide. Either way, we highly recommend fixing sites not to rely on brittle defaults in the mean time.

Thanks. That would help us a lot to keep our current production app running. will wait for the committee decision so that we could take necessary action. 

@ #25: I _highly_ recommend _not_ waiting for the committee decision before you take action, otherwise you're likely to find yourself in the same situation again. ;)

[Automated comment] Request affecting a post-stable build (M46), manual review required.

Approved for M47 (branch: 2526)

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c

commit 0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c
Author: Ulan Degenbaev <ulan@chromium.org>
Date: Mon Oct 19 10:32:52 2015

Version 4.7.80.11 (cherry-pick)

Merged dd3f1ecf719afd21b4c695c776b4da2fb494ef92

Revert of Make dates default to the local timezone if none specified  (https://codereview.chromium.org/1229903004/)

BUG= chromium:539813 , chromium:543320 
LOG=N
R=hablich@chromium.org

Review URL: https://codereview.chromium.org/1413763004 .

Cr-Commit-Position: refs/branch-heads/4.7@{#20}
Cr-Branched-From: f3c89267db0fc6120d95046c3ff35a35ca34614f-refs/heads/master@{#31014}

[modify] http://crrev.com/0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c/src/dateparser-inl.h
[modify] http://crrev.com/0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c/src/dateparser.h
[modify] http://crrev.com/0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c/test/mjsunit/date-parse.js
[modify] http://crrev.com/0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c/test/mjsunit/date.js
[modify] http://crrev.com/0bd963faa7d4e70c5b46abeb1ed2c8bfe40f353c/test/test262/test262.status

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/3b00385a93215ce2a2af737fbea95309b40f08d9

commit 3b00385a93215ce2a2af737fbea95309b40f08d9
Author: Ulan Degenbaev <ulan@chromium.org>
Date: Mon Oct 19 11:46:48 2015

Version 4.6.85.28 (cherry-pick)

Merged dd3f1ecf719afd21b4c695c776b4da2fb494ef92

Revert of Make dates default to the local timezone if none specified  (https://codereview.chromium.org/1229903004/)

BUG= chromium:539813 , chromium:543320 
LOG=N
R=hablich@chromium.org

Review URL: https://codereview.chromium.org/1409343005 .

Cr-Commit-Position: refs/branch-heads/4.6@{#35}
Cr-Branched-From: 24d34a8ae3cad186792fb1e44e2d7c00d49cd181-refs/heads/4.6.85@{#1}
Cr-Branched-From: 8f441181a570c44ef5c949e8dfd9fd326ac10345-refs/heads/master@{#30256}

[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/include/v8-version.h
[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/src/dateparser-inl.h
[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/src/dateparser.h
[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/test/mjsunit/date-parse.js
[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/test/mjsunit/date.js
[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/test/test262-es6/test262-es6.status
[modify] http://crrev.com/3b00385a93215ce2a2af737fbea95309b40f08d9/test/test262/test262.status

When is the next Chrome update(Includes this fix) scheduled to go out ?

Tested this fix on Latest M46#46.0.2490.80 for Win7 64-bit OS, Mac OS X 10.10.5 & Linux Ubuntu 14.04 - Working as intended.

PS: Attached the screen-shot for your reference.

Thank you!

	Screen Shot 2015-10-20 at 3.25.57 PM.png 15.0 KB View Download

This is very weird and is damaging our app.
Check the pic. Left is for 41 (Ubuntu), right is for 46 (Win 7).


text version:
41

new Date('2015-09')
Tue Sep 01 2015 03:00:00 GMT+0300 (MSK)
Date.parse('2015-09')
1441065600000

46:

new Date('2015-09')
Tue Sep 01 2015 00:00:00 GMT+0300 (RTZ 2 (зима))
Date.parse('2015-09')
1441054800000

	Screenshot from 2015-10-21 14:44:01.png 33.8 KB View Download

When will this fix be released?

I don't think it will ever be released, but if it will be, they should hurry. 
This is already implemented in the Beta version of Opera, latest Firefox DEV Edition and will soon be released for end users.

Please read the comments. Comment #38 clarifies that this is fixed in 46.0.2490.80.

Let me emphasise again: we rolled back the change as a temporary measure. If TC39 decides to stick to the spec change (which is not unlikely), then we will reinstantiate it in one of the next releases. I _highly_ recommend fixing your apps not to rely on brittle defaults.

Hi,

When do you estimate the change will be released on the official site of google chrome? 

Thanks

.80 was released. Thank you!

In reply to comment #44:

If you make this change, how do you expect anyone who wants to parse a non-UTC date into the local time zone to do so without relying on any "brittle defaults"?

I think this change is wrong (and am very happy about the rollback, as it was *directly* affecting my web application, just like the above comment #39). JS date handling is already not great, changing it in Chrome to be different from every other browser (and make things even more difficult) is not the answer in my opinion, and will cause developers to have to detect browsers, and even worse, browser version when dealing with dates.

@ #47: You can pad with T00:00Z, although admittedly that's ugly. Also note that Chrome didn't willy-nilly change this, we were trying to follow the new official language spec, in effect since June this year.

But FWIW, the JS committee is now gravitating towards partially reversing the spec change, i.e. date-only strings keep being UTC, while date-time strings are going to be parsed as local time by default. See the discussion at https://github.com/tc39/ecma262/issues/87 -- stay tuned.

@ #48: Thank you for your reply. I do understand Chrome didn't do this willy-nilly, but I also don't think the JS committee is infallible either. Sometimes the ECMA spec does things that don't make sense, and in those times I trust the Chromium developers to do what is right for users and developers, not what is "technically" right but realistically wrong.

The biggest issue is that many, like myself, have built enterprise large web applications in JavaScript against how the browser actually works, not the technical standards (because they don't always match), so when the browser's behaviour changes overnight it's impossible for us (we're not using a SaaS model) to update our application everywhere at once, and customers get affected.

I hope the Chromium team keeps this in mind for changes.

 Issue 549739  has been merged into this issue.

How do you create a Date object that does not convert to local time without having to do something like below (Not relying on defaults)? 

// Date object interprets this ISO date format as UTC, adjust for current timezone
var date = new Date("2014-06-12T09:08:36");
date.setMinutes(date.getMinutes()+date.getTimezoneOffset());

@ #51: One should never EVER try to adjust to a time zone by manually adding or subtracting an offset.  No matter which API you use to do it, it is always wrong because it changes the absolute moment in time that is being represented.

By ISO 8601, and in all other browsers currently:

new Date("2014-06-12T09:08:36")       // users local time
new Date("2014-06-12T09:08:36Z")      // UTC
new Date("2014-06-12T09:08:36-08:00") // specific offset

Chrome is currently conflating the first and second incorrectly.

Also keep in mind that regardless of how the input string is interpreted, the Date object represents an absolute moment in time, having only one internal numeric value that is the number of milliseconds elapsed since 1970-01-01T00:00:00Z, without consideration of leap seconds.  This raw number is given by getTime or valueOf.

HOWEVER, when the Date object is projected to a string, it's always shown in terms of the local time zone, regardless of how the input was determined.

The only exceptions are for those functions that return UTC, such as toISOString, or when the browser supports ECMA-402 provision of allowing the toLocaleString to be passed an optional timeZone parameter.

@ulan, with the clarification in https://github.com/tc39/ecma262/pull/138 can Chrome at least align the date+time form to local which will match the other browsers?  Thanks.

See also http://stackoverflow.com/questions/33524065/javascript-convert-timezone-issue

@ #52:"HOWEVER, when the Date object is projected to a string, it's always shown in terms of the local time zone, regardless of how the input was determined."

This is my problem. Our legacy backend application stores the date value as a raw string in this format "2014-06-12T09:08:36" and our frontend javascript code uses libraries that take Date objects (hence the problem). 

I am looking for a solution that would allow me to avoid this timezone conversion when the libraries use the Date object. Any ideas?

 Issue 544633  has been merged into this issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been TE-Verified and unmodified for over 90 days, so archiving it. Please reopen if it's still valid.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot