Date.getHours() not equal to hours in Date.toLocaleString() in EEST for dates before 1990-06-30
Reported by
iks.soft...@gmail.com,
Jun 8 2017
|
|||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.20 Safari/537.36
Steps to reproduce the problem:
1. set TimeZone to EEST, closest city - Kyiv, Ukraine
2. execute following code
function test(t) {
var date = new Date(t);
console.log(date.toLocaleString(), date.getHours());
}
test('1990-06-30');
3. Observe output
6/30/1990, 4:00:00 AM 3
What is the expected behavior?
Expected output is
either
6/30/1990, 4:00:00 AM 4
or
6/30/1990, 3:00:00 AM 3
What went wrong?
According to
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getHours
"The getHours() method returns the hour for the specified date, according to local time."
Did this work before? N/A
Chrome version: 60.0.3112.20 Channel: dev
OS Version: OS X 10.11.6
Flash Version:
Substituting
test('1990-06-30')
for
test('1990-06-31')
produces
7/1/1990, 3:00:00 AM 3
which is documented behaviour.
,
Jun 10 2017
,
Jun 11 2017
toLocaleString and toHours currently differ in their accuracy. toLocaleString takes into account historical changes in the base of a timezone, whereas toHours
,
Jun 11 2017
... whereas toHours will assume that the base always stays the same. The logic was specified in the ECMAScript specification as such, but it is changing with this patch: https://github.com/tc39/ecma262/pull/778 . The new semantics have not yet bee implemented in V8 (I am partway through implementing them).
,
Jun 11 2017
In particular, it looks like Ukrane was previously under Moscow time (+3), and switched to EEST (+2) one day after the date you listed. The historical time will have a toHours value based on the current timezone, rather than the historical one. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Jun 9 2017