I don't have an access to Windows atm. 

What do you get if you try the following?

new Date(1960,0,1)

You'd not have any issue. 

If the OS tz is already Asia/Tokyo, why do you need to use '+0900'?  

Specifying '+0900' *overrides* the OS timezone setting. Because there are multiple timezones with offset 0900 NOW, it has to pick one out of multiple timezones, Asia/Seoul or Asia/Tokyo.  

Asia/Seoul was UTC+0830 in 1960 while Asia/Tokyo was UTC+0900 in 1960.  

I think Asia/Seoul is always picked when mapping +0900 to an actual timezone. Before 67, v8 didn't take into account the historical timezone offset changes. Now that v8/Chrome does take into account historical changes, you noticed this issue. 

That's a local story. 
Please imagine the case of new date using letters returned from API formatted with +0900. 
Neither the server nor the client has the time zone of the OS in Tokyo, but it is not convinced that the date is shifted only with Windows 7 handled by Korea. Although it is displaying the same screen, it seems that the date is shifted ...

Attached is a screen shot of the reproduction test on the terminal before version upgrade.

Deleted: E16CB007-65B1-4E68-A906-E29AC23EA278.png 244 KB

	E16CB007-65B1-4E68-A906-E29AC23EA278.png 244 KB View Download

Deleted: A272F7E9-F6A1-467C-8BA1-8727A4A327D0.png 284 KB

	A272F7E9-F6A1-467C-8BA1-8727A4A327D0.png 284 KB View Download

Thank you for the additional info. 

 "new Date(1960,0,1)" does have an issue. When the OS timezone is set to Asia/Tokyo, this should not happen. 

What's the output of the following? 

d = new Date(1960,0,1)
d.toLocaleString("en", {timeZoneName: "long"})
d.getTimezoneOffset()

-------------------

As for "new Date('1960-01-01T00:00:00+0900')", '+0900'  should not be mapped to either of Asia/Seoul or Asia/Tokyo.  It should be mapped to "Etc/GMT-9" (note that the sign convention is the opposite).  So, that's clearly a bug. I was wrong about that. However, that's not a new bug but just a latent bug that was exposed by a recent change. 
 

The timezone detection issue seems to be Windows-specific. 

On macOS and Linux, I don't have the problem (with timezone set to Asia/Tokyo):
 
d=new Date(1960,0,1)
Fri Jan 01 1960 00:00:00 GMT+0900 (Japan Standard Time)

Hmm... 

What's the output of the following?

d2=new Date()
d2.toLocaleString("en", {timeZoneName: "long"})
d2.getTimezoneOffset()

Thank you for your reply.

I tried the code. I am still a javascript novice and I do not know what the results will understand, but in this event neither Edge nor firefox occur.

Potential problem?
Is it a problem that occurred because it has been calculated in Seoul and it began to see past data? 
When it was version 66, it was displayed as Japan time ...

Deleted: D2CED3E8-8134-4943-A4AD-D35982FE195C.png 108 KB

	D2CED3E8-8134-4943-A4AD-D35982FE195C.png 108 KB View Download

Thank you for confirming mac OS and Linux. 
This problem does not occur on Windows 10, so it may be a bug in Windows 7.

However, it was still displayed in Tokyo before version upgrade.

Sorry again. 
Details of the reproduction terminal. 
Windows 7 Professional SP 1 32bit 
Belongs to Active Directory

Updating priority seems we're a seeing a lot of reports of breakages

Hi, sorry to burst in.

I wanted to confirm that the issue also happens on Windows 10 on our end and causes many issues. We are using the following date: 1800-01-01 00:00:00

Using "new Date(Date.UTC(1800,0,1,0,0,0))" in Chrome 66 gives "Tue Dec 31 1799 19:00:00 GMT-0500"

Using the same code in Chrome 67 now gives "Tue Dec 31 1799 18:42:28 GMT-0517"

If your timezone setting is Toronto, it is as per the specification, right? 

The problem raised by me is a phenomenon in which historical data of time that is not Toronto is used.

But if the setting of the OS is not Toronto, it is same issue to me.

This is a bug of TimeZone::detectHostTimeZone() in ICU. Please try attached file. On my environment (Windows7 Japanese Edition, 64bit), it display 韓国標準時.

Please upgrade ICU and use uprv_detectWindowsTimeZone on Windows.

Deleted: f0e6cf8f93498adb.png 16.9 KB

	f0e6cf8f93498adb.png 16.9 KB View Download

Forgot to attache source code

Deleted: icu.cxx 492 bytes

icu.cxx 492 bytes View Download

I'm japanese so 韓国標準時 is wrong. 日本標準時 is expected. 

Comment 15 is different from this issue and is NOT a bug. That's WAI. In 1799/1800, there was no standard timezone. So, the zone offset of America/New_York was based on New York's longitude. 

------------
The root cause of this issue (Asia/Tokyo misdetected as Asia/Seoul) is what's in comment 17. ICU's timezone detection has an issue on Win 7. That was my suspicion, but haven't managed to confirm that on Win 7, yet. (I need to find a Windows machine or VM to test). 

Thank you, mattn.jp@, for confirming that. 

Reported an upstream bug at http://bugs.icu-project.org/trac/ticket/13826 . 

https://cs.chromium.org/chromium/src/third_party/icu/source/common/wintz.cpp?rcl=f61e46dbee9d539a32551493e3bcc1dea92f83ec&l=183  talks about Seoul and Tokyo.

Excuse me. I currently do not have an environment to compile cxx files.

From the ICU source, the cause is fixed by this?

Do you know when version is "//src/third_party/icu/source/common/wintz.cpp"?

Is it the case with the latest ICU?

For the time being, my PG corresponded as shown.
 This will be displayed in Japan time in any environment.
(This system is used only in Japan)
Is there any problem?

Deleted: 435208D4-6476-4BFF-8C2E-79EECFC5E154.png 93.0 KB

	435208D4-6476-4BFF-8C2E-79EECFC5E154.png 93.0 KB View Download

If your version of ICU have uprv_detectWindowsTimeZone, you've better to call it.

It is not my program to use ICU but chrome. 
Or is there something I can do?

Even if it is fixed by updating to the latest ICU, it can not be set up on all terminals of the customer.

re comment 26:

Chrome bundles ICU. If a fix is found for ICU, Chrome will be updated to include the fix for ICU. 

You can follow along at http://bugs.icu-project.org/trac/ticket/13826.  Not having a Windows 7 machine (let alone a Japanese Windows [1]) makes it very hard to test/debug. 

Unless one has a multilingual pack for Windows 7, it's not possible to switch the OS display language to Japanese. Even on a monolingual Windows 7, I can switch the default code page for non-Unicode app to Shift_JIS, but that may nor may not be sufficient to reproduce this issue. 

I checked the ICU side ticket. 
It seems to happen in Windows other than English.
It was a difficult technique to find this.
If the registry of the ticket is defined with a string, that is the cause. 

Thank you very much for having a relationship with the problems of Japanese little programmers this time.
It was a great learning experience.
I will keep watching Chrome and the better growth of the web world from now on. 
I am thankful to all the great programmers.

I was able to reproduce the issue in a Windows 7 VM with the display language set to Korean.  

A Microsoft engineer was also able to reproduce the issue with an standalone ICU test program. So, it's most likely to be due to a bug ICU's Windows timezone detection function By code inspection alone,  it appears to be ok except that there are a lot of unnecessary code, but the MS engineer used a debugger and believes that he identified the cause. He'll come up with a fix. 

Once the fix is available, I'll chery-pick it and merge to Chrome 67 after baking in the canary/dev. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/deps/icu.git/+/172d33141cd16df9d027cfd49bfe940b1dc66f1a

commit 172d33141cd16df9d027cfd49bfe940b1dc66f1a
Author: Jungshik Shin <jshin@chromium.org>
Date: Sat Jun 09 04:12:10 2018

Fix timezone detection on Japanese/Korean Windows

ICU's Windows timezone detection is broken on Japanese/Korean
(and potentially other non-English) Windows.

Cherrypick the upstream fix.
See http://bugs.icu-project.org/trac/ticket/13826 .

TBR=gsathya@chromium.org
Bug:  849724 
Test: Set the timezone to Tokyo on Japanese Windows
Test: In JS console, 'new Date()' outputs 'Japan Standard Time' in parens.
Change-Id: Ie76c1e97ee2e965825f2fe99442c55e797b45f41
Reviewed-on: https://chromium-review.googlesource.com/1094322
Reviewed-by: Jungshik Shin <jshin@chromium.org>

[modify] https://crrev.com/172d33141cd16df9d027cfd49bfe940b1dc66f1a/README.chromium
[add] https://crrev.com/172d33141cd16df9d027cfd49bfe940b1dc66f1a/patches/wintz.patch
[modify] https://crrev.com/172d33141cd16df9d027cfd49bfe940b1dc66f1a/source/common/wintz.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/230693524f30b43a7ab418ef8106dc3a566701a7

commit 230693524f30b43a7ab418ef8106dc3a566701a7
Author: Jungshik Shin <jshin@chromium.org>
Date: Sun Jun 10 08:22:17 2018

Roll ICU to 172d33141

This roll has just one change to fix the timezone
detection on Japanese/Korean and other non-English
Windows.

  https://chromium-review.googlesource.com/1094322

TBR=gsathya@chromium.org

Bug:  849724 
Test: Set the timezone to Tokyo on Japanese Windows
Test: In JS console, 'new Date()' outputs 'Japan Standard Time' in parens.
Change-Id: I0bddf33e1490b2b795504002d975252347e9d568
Reviewed-on: https://chromium-review.googlesource.com/1094327
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565906}
[modify] https://crrev.com/230693524f30b43a7ab418ef8106dc3a566701a7/DEPS

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/92920eb235b6d5d47e9e5f360838d4736b91fe06

commit 92920eb235b6d5d47e9e5f360838d4736b91fe06
Author: Hayato Ito <hayato@chromium.org>
Date: Mon Jun 11 05:57:29 2018

Revert "Roll ICU to 172d33141"

This reverts commit 230693524f30b43a7ab418ef8106dc3a566701a7.

Reason for revert:

Consistent failures on Win7 Tests (1) [18 out of the last 18 builds have failed].

external/wpt/html/dom/documents/resource-metadata-management/document-lastModified-01.html

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=external%2Fwpt%2Fhtml%2Fdom%2Fdocuments%2Fresource-metadata-management%2Fdocument-lastModified-01.html&testType=webkit_layout_tests

e.g.
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20Tests%20%281%29/80749


Original change's description:
> Roll ICU to 172d33141
> 
> This roll has just one change to fix the timezone
> detection on Japanese/Korean and other non-English
> Windows.
> 
>   https://chromium-review.googlesource.com/1094322
> 
> TBR=gsathya@chromium.org
> 
> Bug:  849724 
> Test: Set the timezone to Tokyo on Japanese Windows
> Test: In JS console, 'new Date()' outputs 'Japan Standard Time' in parens.
> Change-Id: I0bddf33e1490b2b795504002d975252347e9d568
> Reviewed-on: https://chromium-review.googlesource.com/1094327
> Reviewed-by: Jungshik Shin <jshin@chromium.org>
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#565906}

TBR=jshin@chromium.org,gsathya@chromium.org

Change-Id: I4b9e37bbe93fea628e2d2a94eabd3d983d9b551d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  849724 
Reviewed-on: https://chromium-review.googlesource.com/1094856
Reviewed-by: Hayato Ito <hayato@chromium.org>
Commit-Queue: Hayato Ito <hayato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565931}
[modify] https://crrev.com/92920eb235b6d5d47e9e5f360838d4736b91fe06/DEPS

The webkit layout test is cryptic. I have little idea how the ICU change (it is about time, but still lastModified date test should not be affected) can lead to lastModifiedDate layout test failure on Windows. Moreover, the CQ passed the test at least once (otherwise, the ICU roll CL wouldn't have been landed)...

Anyway, I'll find a way to test 'lastModifiedDate' layout test on a Windows (vm or actual). 

In the meantime, I confirmed that the ICU change did fix this bug in snapshot build of 565912 [1]. That build was cut between my ICU change roll (comment 32)  and the revert
 (comment 33)


[1] https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/565912/ 

Hmm... the failed test that led the CL to be reverted was 

external/wpt/html/dom/documents/resource-metadata-management/document-lastModified-01.html . 

I thought it was fast/js/lastModified.html . 

I can't reproduce the failure locally (I still don't have a Windows build machine, but was able to run the failed layout test with a version of Chrome with ICU rolled to the latest; win32 build 565912 has a fix).  

However, win 7 try bot ( 
https://test-results.appspot.com/data/layout_results/win7_chromium_rel_ng/12794/layout-test-results/results.html ) has this output: 

This is a testharness.js-based test.
FAIL Date returned by lastModified is current at page load assert_approx_equals: expected 1528794903 +/- 2.5 but got 1528798502
PASS Date returned by lastModified is in the form "MM/DD/YYYY hh:mm:ss".
FAIL Date returned by lastModified is in the user's local time zone. assert_approx_equals: Hours and minutes should match local time. expected 4502 +/- 2 but got 8102
FAIL Date returned by lastModified is current after timeout. assert_approx_equals: (initial value was 1528798502) expected 1528794907 +/- 2.5 but got 1528798506
Harness: the test ran to completion.

There is an hour offset between expected and actual. Hmmm..


The above test was done with timezone set to Asia/Tokyo. 

When I switched back to America/Los_Angeles, I could reproduce the failure locally. 

Somehow, document.lastModified is off by 1 hour. document.lastModified is calculated entirely by Blink not using v8 (which in turn uses ICU) but directly using Windows APIs. 
 

The ICU change is to switch to 'W' API (from 'A' API) for registry access to detect the current timezone. I have little idea how the ICU change can affect Blink's current time calculation. 

Blink's document.lastModified :
third_party/blink/renderer/platform/wtf/date_math.cc
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/document.cc?rcl=2111e0cf2eec22a80d0492eeb121686d281c98e5&l=5347

> I have little idea how the ICU change can affect Blink's current time calculation. 

On Windows, Blink uses GetTimeZoneInformation (Windows API) and localtime_s to calculate the timezone offset.  I need to debug on a Windows box..

I guess the failure should occur just randomly.  Take a look at http://bugs.icu-project.org/trac/ticket/13826#comment:18

mozo@:  What is failing does not use ICU at all. document.lastModified is calculated using Windows APIs (GetTimeZoneInformation and localtime_s). Somehow ICU change I cherry-picked made them behave differently. That ICU change is basically using 'W' API instead of 'A' API.  

A new CL is up: 
https://chromium-review.googlesource.com/c/chromium/src/+/1100739

When calculating lastModified, the CL uses ICU timezone as v8 does. 

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

commit 3f6b6de6287031ef79650af9898d783074cfebd2
Author: Jungshik Shin <jshin@chromium.org>
Date: Thu Jun 21 15:01:49 2018

Roll ICU to 172d331 and use icu tz in wtf

This roll has just one change to fix the timezone
detection on Japanese/Korean and other non-English
Windows.

  https://chromium-review.googlesource.com/1094322

In addition, switch to ICU to convert UTC to local time
in blink. This is to deal with a cryptic failure of
external/wpt/html/dom/doc*/resource*/document-lastModified-01.html

parens.

Bug:  849724 
Test: Set the timezone to Tokyo on Japanese Windows
Test: In JS console, 'new Date()' outputs 'Japan Standard Time' in
Test: Layout test external/wpt/html/dom/doc*/resource*/document-lastModified-01.html
Change-Id: I3037252ff9044a114ae831de2b151df7c652603c
Reviewed-on: https://chromium-review.googlesource.com/1100739
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569262}
[modify] https://crrev.com/3f6b6de6287031ef79650af9898d783074cfebd2/DEPS
[modify] https://crrev.com/3f6b6de6287031ef79650af9898d783074cfebd2/third_party/blink/renderer/platform/wtf/date_math.cc

Will bake in the canary/dev.