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

Issue 797548 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Date.prototype.toLocaleTimeString incorrectly renders hour for some dates between 1968 and 1971

Reported by ni...@electricimp.com, Dec 24 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
Using chrome from the Europe/London timezone.
From the dev console:

x = new Date(1972, 0, 1, 6, 0)
Sat Jan 01 1972 06:00:00 GMT+0000 (GMT)
x.toLocaleTimeString("en", {hour: "numeric"})
"6 AM"
x = new Date(1970, 0, 1, 6, 0)
Fri Jan 01 1970 06:00:00 GMT+0000 (GMT)
x.toLocaleTimeString("en", {hour: "numeric"})
"7 AM"

What is the expected behavior?
The hour returned should match the hour in the Date object

What went wrong?
For dates between the last Sunday in October and the last Sunday in March, starting in October 1968 and ending in October 1971, the returned hour is one hour ahead of what it should be.

Did this work before? N/A 

Chrome version: 63.0.3239.84  Channel: stable
OS Version: Ubuntu GNOME 16.04
Flash Version: 

According to https://en.wikipedia.org/wiki/British_Summer_Time, the UK experimented with having daylight saving run throughout the year for the affected dates. It would seem this is being inconsistently accounted for.

This is particularly troublesome because the unix epoch is often used as a placeholder date, and falls within this range.
 
This originated from my investigations into a home-assistant bug. The relevant issue is here: https://github.com/home-assistant/home-assistant/issues/10784

I mention this because somebody there is experiencing the same issue in Aukland
Labels: Needs-Triage-M63
Components: -Blink Blink>JavaScript
Cc: vamshi.k...@techmahindra.com
Labels: Triaged-ET Needs-Feedback
Checked the issue on reported chrome version 63.0.3239.84 and on the latest canary 65.0.3305.0 using Ubuntu 14.04 with the below mentioned steps.
1. Launched chrome
2. Have set the time zone to London
3. Opened dev tools>Console
4. Given the inputs : x = new Date(1972, 0, 1, 6, 0)
                                 x.toLocaleTimeString("en", {hour: "numeric"})
                                 x = new Date(1970, 0, 1, 6, 0)
                                 x.toLocaleTimeString("en", {hour: "numeric"}) 

and got the results:  Sat Jan 01 1972 06:00:00 GMT+0000 (GMT)
                                "6 AM"
                                Thu Jan 01 1970 06:00:00 GMT+0000 (GMT) 
                                "7 AM"          respectively for above mentioned inputs. Attaching the screen cast of the same.

@Reporter: Could you please have a look at the screen cast and let us know, getting the output as "Thu Jan 01 1970 06:00:00 GMT+0000 (GMT)" instead of  "Fri Jan 01 1970 06:00:00 GMT+0000 (GMT) "  by giving the third input is the issue as per your comment#0. Any further inputs from your end helps us to triage the issue in a better way.

Thanks!
797548.mp4
2.5 MB View Download
Suspect that's a transcription error in my initial bug report, was copying from a mess of places. Ran the repro in a clean console and got:

x = new Date(1972, 0, 1, 6, 0)
Sat Jan 01 1972 06:00:00 GMT+0000 (GMT)
x.toLocaleTimeString("en", {hour: "numeric"})
"6 AM"
x = new Date(1970, 0, 1, 6, 0)
Thu Jan 01 1970 06:00:00 GMT+0000 (GMT)
x.toLocaleTimeString("en", {hour: "numeric"})
"7 AM"

"7 AM" is the incorrect time, it should read "6 AM", that is the bug I'm reporting
Project Member

Comment 6 by sheriffbot@chromium.org, Dec 28 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: M-65 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
As per the comment#5 by reporter we are able to reproduce the issue on reported chrome version 63.0.3239.84 and on the latest canary 65.0.3305.0 using Ubuntu 14.04, Windows 10 and Mac 10.13.1. 

As the issue is seen from M50 (50.0.2634.0) considering it as non-regression, hence marking it as Untriaged.

Thanks!
Components: -Blink>JavaScript Blink>JavaScript>Internationalization
Status: Available (was: Untriaged)
Project Member

Comment 9 by sheriffbot@chromium.org, Jan 2

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)

Sign in to add a comment