New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 696965 link

Starred by 1 user
Status: WontFix
Owner:
█ littledan@chromium.org
Last visit > 30 days ago
Closed: Mar 2017
Cc:
js...@chromium.org
hablich@chromium.org
adamk@chromium.org
u...@chromium.org
verwa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Date.parse ignores system timezone when parsing ISO8601 without time zone designator

Reported by jozefchu...@gmail.com, Feb 28 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. have your system timezone offset something other then 0. i.e. use CET 
2. check new Date().getTimezoneOffset() correctly returns -60
3. see Date.parse("1970-01-01T00:00:00") returns 0

What is the expected behavior?
Date.parse("1970-01-01T00:00:00") should return -3600000 while it returns 0

What went wrong?
According to ISO 8601 https://en.wikipedia.org/wiki/ISO_8601 "If no UTC relation information is given with a time representation, the time is assumed to be in local time."

With the correct parser implementation, I would expect the datetime string should be interpreted as local time and so the output timestamp to be -3600000.

IE11, Edge and FireFox seems to return expected -3600000.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 10.0
Flash Version:

Comment 1 by krajshree@chromium.org, Mar 2 2017

Components: Blink>JavaScript>Runtime
Labels: -Type-Bug -Pri-2 M-58 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: littledan@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.2, Win-10 and Ubuntu 14.04 using chrome reported version #56.0.2924.87 but the same is not reproducible in the latest canary #58.0.3027.0.

Reverse Bisect Information:
=====================
Good build: 58.0.3015.0  Revision(451180)
Bad Build : 58.0.3014.0  Revision(450840)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/156ba9177eb266804d52f98c1e17033705645b5d..f833b45c4615349644227cac888baf86c1963020

As the above CL is related to V8-autoroll, so another CL from V8-autoroll is as follows:
https://chromium.googlesource.com/v8/v8/+log/ec3ce5bd..6346f598

From the above change log suspecting below change

Review url: https://codereview.chromium.org/2648603002

littledan@ - Could you please check and merge the fix to M-58 if it is a valid candidate.

Thanks...!!

Comment 2 by littledan@chromium.org, Mar 2 2017

Cc: u...@chromium.org js...@chromium.org adamk@chromium.org hablich@chromium.org
The behavior before the patch is long-standing Chrome behavior, based on a previous specification. The new behavior has unknown compatibility risks--sites which are targeted towards Chrome may depend on the old behavior. Even though the patch would be easy to backport, I'd prefer to let it roll out gradually through the canary/dev/beta release train to discover compatibility issues.

I cc'd some more people who have been involved in V8 Date issues and backports; I'd be interested if anyone has any more thoughts.

Comment 3 by adamk@chromium.org, Mar 2 2017

Labels: -Pri-1 Pri-2
Status: WontFix (was: Assigned)
Given that the "bad" behavior is long-standing Chrome behavior, I don't think we want to backport this.

Also, I don't think I'd say this is a "regression". Marking as "WontFix", as in, "already fixed in most recent version".
►

Sign in to add a comment