Any information here about workarounds here. For us this bug breaks support of our web app for some big customers.

Same issue as https://bugs.chromium.org/p/chromium/issues/detail?id=896759

Able to reproduce the issue on reported version 71.0.3578.80 and on latest chrome# 73.0.3635.0 using Windows-7, hence providing Bisect Info
Note: Issue is specific to Windows-7

Bisect Info:
================
Good build: 71.0.3575.0
Bad build: 71.0.3576.0

On running per-revison and chromium bisect getting error, hence providing below change-log from omahaproxy
Change-Log: https://chromium.googlesource.com/chromium/src/+log/71.0.3575.0..71.0.3576.0?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/fec152acbf487c58de34152b7f4e641b790d83c8 from above change log
Change-Id: I792e68bedaa6065d8d9886aa3ef5c15988f1d43e
Reviewed-on: https://chromium-review.googlesource.com/c/1270520

@Jungshik Shin: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable for M-71, feel free to remove it if not applicable.

Thanks!

 Issue 913290  has been merged into this issue.

 Issue 913288  has been merged into this issue.

 Issue 896759  has been merged into this issue.

Chrome gTech chiming in. We're seeing some feedback related to timezones being off by one hour, possibly related to DST. Not all of them are related to AEDT (some are from areas in Europe).

Listnr:
- https://listnr.corp.google.com/report/85837529054
- https://listnr.corp.google.com/report/85836428819
- https://listnr.corp.google.com/report/85836400989
- https://listnr.corp.google.com/report/85832931911
- https://listnr.corp.google.com/report/85832319510

reddit:
- https://www.reddit.com/r/chrome/comments/a3l8wf/help_chromes_tim895769ezone_isnt_the_same_as_my_actual/

Actual feedback volumes are low, but it's possible users are reporting the issue to web service developers instead of Chrome in-product.

I confirm I've seen some similar feedback on other libraries/services issue tracker, for example moment.js : https://github.com/moment/moment/issues/4892
Can't tell if it's linked, this report is about Android, the others are Windows 7 only.

I've found some on other boards too, e.g https://stackoverflow.com/questions/53644999/new-zealand-daylight-saving-time-broken-in-chrome-71

I think you find more feedbacks from AEDT / NZ zones on Chrome 71 stable because it has been released whereas DST is currently "on" there.
In my case (Europe/Paris) I only encounter this bug for future dates from 31/03/2019 (next DST switch), cf  Issue 896759 .
Moreover, first feedbacks from 896759 (before Chrome 71 went stable) occurred on North hemisphere in October, before DST switched off.

This my version number of Chrome: Version 71.0.3578.80 (Official Build) 
(32-bit)

Leigh Tingle...

On 11/12/2018 3:03 am, a… via monorail wrote:

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

commit 59dcf5c4d54245ab5e650663dd2318f3cdcfc880
Author: Jungshik Shin <jshin@chromium.org>
Date: Mon Dec 10 22:35:10 2018

[M71] Roll icu to 751b6431c06

It has one commit, which reverts this change:

  https://chromium-review.googlesource.com/c/1270635

As a result, bug 854387 will regress in M71 while  bug 913298  is fixed.
We're taking this trade-off given the M71 stable schedule.

See
https://chromium.googlesource.com/chromium/deps/icu.git/+log/b029971..751b643

TBR=govind@chromium.org

Bug: 854387,  913298 
Test: see the bug
Change-Id: I63df2f5bc6a485a7c21dbbf4efd16b0273ccba69
Reviewed-on: https://chromium-review.googlesource.com/c/1370582
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#891}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/59dcf5c4d54245ab5e650663dd2318f3cdcfc880/DEPS

Here's a summary of the rules that were executed: 
 - OnlyMergeApprovedChange: Rule Failed -- Revision 59dcf5c4d54245ab5e650663dd2318f3cdcfc880 was merged to refs/branch-heads/3578 branch with no merge approval from a TPM! 
Please explain why this change was merged to the branch!
 - AcknowledgeMerge: Notification Required -- 

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

Commit: 59dcf5c4d54245ab5e650663dd2318f3cdcfc880
Author: jshin@chromium.org
Commiter: jshin@chromium.org
Date: 2018-12-10 22:35:10 +0000 UTC

[M71] Roll icu to 751b6431c06

It has one commit, which reverts this change:

  https://chromium-review.googlesource.com/c/1270635

As a result, bug 854387 will regress in M71 while  bug 913298  is fixed.
We're taking this trade-off given the M71 stable schedule.

See
https://chromium.googlesource.com/chromium/deps/icu.git/+log/b029971..751b643

TBR=govind@chromium.org

Bug: 854387,  913298 
Test: see the bug
Change-Id: I63df2f5bc6a485a7c21dbbf4efd16b0273ccba69
Reviewed-on: https://chromium-review.googlesource.com/c/1370582
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#891}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

Sorry I was in hurry for onsite interview and skipped steps.

This is going back to m70 behavior and is safe. Because trunk has icu 63, trunk cannot take revert. So, the revert directly went to m71 branch with icu 62.

Thank you jshin@. This merge was approved for M71 via offline chat. 

Is this need a merge to M72? Currently M73 is in trunk.

Removing "Merge-Without-Approval" per comment #19.

Comment 11:

1st report was in a non-English version of Windows. So I suspected that it may have something to do with a potentially localized timezone name, but the 2nd report is very likely to be from en-AU Windows. 

report #2:

Description
There is an issue with 32 bit Chrome and Windows 7. We have a website which takes the time from the local machine but with the latest version of Chrome, the time is showing as 1 hour out. We have only so far encountered this problem with 32 bit on Windows 7. We have checked the system times and the timezones etc. If we change the timezone to Brisbane (currently same time as us) the browser clock changes to 12 hours out! This problem only occurs on Chrome, IE and Firefox are both ok.

report #1:
---------
On a Windows 7 machine with Chrome v71 the time zone cannot be determined. This causes all sort of date related problems. With Chrome v70 on the same machine the time zone can be determined. The call to Intl.DateTimeFormat().resolvedOptions().timeZone will return the expected result "Europe/Amsterdam" with Chrome v70.

Additional information: the machine is accessed by RDP, as it runs as a VMWare image.
------------

report #3:

When using the latest issue of 32 bit Chrome on Windows 7, the time shows incorrectly, being 1 hour out when set to Sydney. The system time is currently 10:14 and the timezone is correct. This only happens on lastest install of Chrome and only on Windows 7. We have tested on 32 bit Windows 10 and all is working ok.
https://seahawk.marinerescuensw.com.au/home/index 

I have used a workaround by setting my time zone to Bougainville 
Island(UTC+11), I just have to remember to change back to Sydney time 
(UTC+10) around April 2019.

On 11/12/2018 12:06 pm, js… via monorail wrote:

Able to reproduce the issue on chrome reported version 71.0.3578.80(Build without fix)
Verified the fix on Windows-7 on Chrome version #71.0.3578.95 as per the comment#0
Attaching screenshot for reference.
Observed "Output from the 'new Date' command is exactly matching the system time on the computer"
Hence, the fix is working as expected.
Adding the verified label.

Deleted: 913298.PNG 105 KB

	913298.PNG 105 KB View Download

Thank you. Can you kindly let me know when this patch would be released?

I am also troubleshooting this timezone issue with Chrome, except I am on Windows 10

Deleted: chrome_bug1.PNG 70.3 KB

	chrome_bug1.PNG 70.3 KB View Download

 Issue 913966  has been merged into this issue.

 Issue 913963  has been merged into this issue.

I'm trying to reproduce this issue in a standalone v8. Not having a physical Windows box makes it a bit tricky. I'm still setting up a v8 dev environment on Windows 7 VM. 

M71 should be fine now with a revert recorded in comment 17. 

Re: comment 25:  On Windows 10, did you change timezone while Chrome was running?  

On Windows 7 VM,  I observed this:

1. Start Chrome
2. new Intl.DateTimeFormat("en").resolvedOptions().timeZone =>  undefined
3. Change the timezone in the control panel
4. new Intl.DateTimeFormat("en").resolvedOptions().timeZone => Etc/Unknown 

 viswa.karala@chromium.org : thank you for verifying.  Can you also try what I wrote in comment 28 as well?  

In step 2, you should not get 'undefined'. Instead, you should get 'America/Los_Angeles' (if you're in US Pacific timezone)
In step 3, change the OS timezone to, say, Sydney,Canberra, Melbourne time. Then, In step 4, you should get 'Australia/Sydney'. 
 

Sorry if this is he correct place to post this (maybe i should have created a new thread instead?)

We're experiencing this very bad bug in our main business application.
Our timezone is "(UTC+01:00) Brussels, Copenhagen, Madrid, Paris" with DST

While new Date() gives the correct date with the (GMT+1) indication,
new Date(2018, 5, 20) (which is in summertime) also gives us (GMT+1) instead of the expected (GMT+2)

Our users cannot access data from dates in summertime, because every date parameter is 1 hour off.

Tested in Version 71.0.3578.80 but also in Chromium Version 73.0.3638.0

Re: Comment# 29: 
Able to reproduce as mentioned in comment# 28 on chrome version# 71.0.3578.80 and 
It is working as excepted on chrome version# 71.0.3578.98 as shown in comment# 29, please find the attached screenshot for reference.

Thanks!

Deleted: 913298.PNG 55.5 KB

	913298.PNG 55.5 KB View Download

I've encountered a probably related issue with latest Chrome 71.x stable on Windows 7. Couldn't test on latest Windows Versions though.

The following snippet returns a different result on Windows 7 while using Berlin timezone in OS settings:

new Date(1554069600000).getTimezoneOffset() 

Mac/Linux: -120
Windows 7: -60
Firefox: -120
Safari: -120


As a consequence new Date(1554069600000) formats into "31/03/2016 23:00" on Windows 7 instead of "01/04/2016 00:00" on every other OS/browser. This issue didn't exist in Chrome 70.x.

Do you have any idea when the version will be released ?

We developp a time management application and our thousands of users cannot work with

re: comment 31 - thank you for checking 

Chrome 71 will be updated pretty soon with a fix submitted (see comment 17).

For M72/73,  my attempt to reproduce this issue in a v8 standalone failed. I spent a few hours to get 'fetch v8' to work on Windows 7 x86 vm before realizing that I need a 64bit Windows (gn failed) !   Will try tomorrow on Win 7 64bit.

 viswa.karala@, can you do more testing as following?

On both Windows 10 and Windows 7 with 3578.80 (before the fix) and M72/M73 

1. start Chrome 
2. Go to http://jungshik.github.io/cr/bugs/520783.html and record the output
3. Change the OS timezone to Sydney/Canberra/Melbourne
4. At http://jungshik.github.io/cr/bugs/520783.html (you visited in step 2), click on 'recheck' button

Thank you   
  

Tested the issue on chrome versions# 71.0.3578.80, #71.0.3578.98, #72.0.3626.14, # 73.0.3638.0 using Windows-10 & 7. Please find the attached sheet for details observations.

Thanks!

Deleted: 913298.xlsx 10.7 KB

913298.xlsx 10.7 KB Download

All tests to validate 71.0.3578.98 ask for a timezone-change on OS-level.

Can anyone @chromium confirm that the other use-case is also fixed in that version? I cannot find a compiled version of #71.0.3578.98 and can't take the time to setup an environment to compile this myself...

The test is simple:
1) Have a Windows 7 with a DST timezone like (UTC+01:00) Brussels, Copenhagen, Madrid, Paris
2) Verify output of a summertime date or its timezone offset 
(new Date(1554069600000).getTimezoneOffset() should output -120 and not -60 in our case)

We are very eagerly waiting for a fix in stable channel...

Thanks  a lot, viswa.karala@ !  

This confirms that ONLY Windows 7 has this issue, while Windows 10 is fine. 

> This confirms that ONLY Windows 7 has this issue, while Windows 10 is fine.

And, also confirms that the change recorded in comment 17 works for Windows 7.  (well, it regressed bug 854387 unfortunately for Windows 10). 

re: comment 38: M71 stable will be updated with the fix in comment 17 in a couple of days. 

In the meantime, I filed an upstream bug at 
   https://unicode-org.atlassian.net/browse/ICU-20302  

Good news: 71.0.3578.98 is now available with the fix on Chrome Stable. You can force an update by visiting chrome://chrome. Thank you.

Will there be an automatic update available for this?
If I restart my machine will chrome automatically update this?
The reason I'm asking this is to know if my users will automoatically get updated on their chrome / System restart or should I ask them to do a manual update by visiting chrome://chrome ??

If you update Chrome manually, the changes take affect. You do not need to reboot the computer.

This is Leigh Tingle
Thank you for your sterling effort to resolve this issue, much appreciated.
Have a Happy Christmas.

Applied manual update in AEDT timezone. All fixed. Thanks.

Can this be marked as fixed now or Remove "RBS" label?

Thank you developers !

Issue is resolved.
Thanks for the update!

> Can this be marked as fixed now or Remove "RBS" label?

Not yet. We haven't fixed M72 and M73. 

Fortunately, the upstream found the root cause of this issue and has a CL under review. See https://unicode-org.atlassian.net/browse/ICU-20302  .  

I'll try to get that in later today, but I might not be able to get it in time for M72 beta cut.   

I can certainly do it tonight. If I miss the first beta train for M72, I have to backport it to M72 branch after the 1st M72 beta. 

I'll also add a test for this on Windows. Testing the timezone on Windows is tricky, but at least a test can be added to make sure that Intl.DateTimeFormat.resolvedOptions.timeZone is not 'undefined'.  

> Remove "RBS" label?
Dropped it. Should I add RBB?  

Issue 914330 has been merged into this issue.

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

commit 699e35e3d90573389188c825bbbf98995743dc5d
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri Dec 14 07:50:36 2018

Cherry-pick a Windows 7 timezone detection fix

Windows 7 has a 'bug' in one of its timezone APIs. ICU's
timezone detection code was hardened to work 'around' the
bug.

Upstream bug: https://unicode-org.atlassian.net/browse/ICU-20302
Upstream fix: https://github.com/unicode-org/icu/pull/315

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

Bug:  913298 
Test: See bug comment 35
Change-Id: Ib13b6a2809c629929490c5bfd73bee93b2c918c2
Reviewed-on: https://chromium-review.googlesource.com/c/1377557
Reviewed-by: Jungshik Shin <jshin@chromium.org>

[modify] https://crrev.com/699e35e3d90573389188c825bbbf98995743dc5d/README.chromium
[add] https://crrev.com/699e35e3d90573389188c825bbbf98995743dc5d/patches/win7_tz.patch
[modify] https://crrev.com/699e35e3d90573389188c825bbbf98995743dc5d/source/common/wintz.cpp

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

commit 23de01679d298bf9fb964ebede32f2157729ba96
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri Dec 14 19:55:09 2018

Fix Win component build failure

Windows component build with clang has this compile error.

icu_63::uprv_detectWindowsTimeZone' should not add 'dllexport' attribute
[-Werror,-Wdll-attribute-on-redeclaration]
uprv_detectWindowsTimeZone()

Cherry-pick https://github.com/unicode-org/icu/pull/318

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

Bug:  913298 
Test: Windows component build compiles w/o any error.
Change-Id: I45fc8ac2c1f5fa7821178fea5985c5df6afea850
Reviewed-on: https://chromium-review.googlesource.com/c/1377561
Reviewed-by: Jungshik Shin <jshin@chromium.org>

[modify] https://crrev.com/23de01679d298bf9fb964ebede32f2157729ba96/README.chromium
[modify] https://crrev.com/23de01679d298bf9fb964ebede32f2157729ba96/patches/win7_tz.patch
[modify] https://crrev.com/23de01679d298bf9fb964ebede32f2157729ba96/source/common/wintz.h

BTW,  v8 has a test for checking Intl.DateTimeFormat(...).resolvedOptions().timeZone, but it is disabled because it's flaky. Windows 7 vm images seem to have an issue with the timezone registry. See bug 856119 .  

This issue would have been caught much earlier if the test had not been disabled. I'll use bug 856119 to fix Windows 7 vm images used by v8 (and chormium) trybots. 

In the meantime, I'll roll ICU in trunk to 23de01679d2. 

https://chromium-review.googlesource.com/c/chromium/src/+/1379250 is a fix.

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

commit 653848993f375e13ff911963431e3e682d2dae6c
Author: Jungshik Shin <jshin@chromium.org>
Date: Mon Dec 17 08:26:27 2018

Roll ICU to 23de0167

This is to cherry-pick two upstream changes to fix the timezone detection
on Windows 7. Windows 7 timezone API has a 'bug' that needs to be worked
around in ICU.

https://chromium.googlesource.com/chromium/deps/icu.git/+log/2823bdd..23de016

Besides, add a web test:
  fast/js/regress/script-tests/resolved-timezone-defined

It's marked as flaky on Win7 due to https://crbug.com/856119 .

Bug:  913298 
Test: fast/js/regress/resolved-timezone-defined
Change-Id: I4b5b766c7b3a65c55f8c18f93c5a5a9a85f02f6b
Reviewed-on: https://chromium-review.googlesource.com/c/1379250
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617064}
[modify] https://crrev.com/653848993f375e13ff911963431e3e682d2dae6c/DEPS
[modify] https://crrev.com/653848993f375e13ff911963431e3e682d2dae6c/third_party/blink/web_tests/TestExpectations
[add] https://crrev.com/653848993f375e13ff911963431e3e682d2dae6c/third_party/blink/web_tests/fast/js/regress/resolved-timezone-defined-expected.txt
[add] https://crrev.com/653848993f375e13ff911963431e3e682d2dae6c/third_party/blink/web_tests/fast/js/regress/resolved-timezone-defined.html
[add] https://crrev.com/653848993f375e13ff911963431e3e682d2dae6c/third_party/blink/web_tests/fast/js/regress/script-tests/resolved-timezone-defined.js

Should be fixed in the trunk / M73. 

viswa.karata@ :  can you verify the fix in canary (once it's available) build or any build after the commit position #617064 ?  You can use the same procedure used in comment 35 and comment 36. 

Thanks !

Once the fix is verified,  I'll ask for merge to M72 and probably M71 as well because the emergency fix for M71 regressed bug 854387.

Is this issue completely resolved for Windows 7 in Chrome 71.0.3578.98? I have a user who just updated the browser to 71.0.3578.98 and Intl.DateTimeFormat().resolvedOptions().timeZone still returns undefined.

re: commen 60
Yes, this should be fixed in M71. M71 is the same as M70 as far as this bug is concerned. That is, if M71 has this issue still outstanding, M70 must have the same issue on that user's machine: 

Ask them to run the following command and give you the output. 

reg query 'HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation'


or 

reg query HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v TimeZoneKeyName

I've just tried 73.0.3644.0 with ICU rolled to 23de0167 (continuous build #617390) and confirmed that the issue is resolved in the build. 

I'll wait for next canary build to come out and try again before asking for merge to M72. 

It looks like my user's issue was resolved with the latest stable chrome update but it seemed like a PC restart may have helped. Thank you for the help :)

re: comment 63: It's strange because Windows restart shouldn't be required. Anyway, it's good to hear that the issue was resolved for your users. 

----------

73.0.3645.0 is also fine. Asking for merge to M72 branch the following two changes. It'll be done by rolling ICU to include those two changes. 

https://chromium-review.googlesource.com/c/1377557
https://chromium-review.googlesource.com/c/1377561

With the two CLs combined, there are 3 lines of code changes, of which only one is substantial (the change is to replace one function argument with -1).   Other two lines are for function declaration change to add a regression test in ICU. 

It should be safe and confirmed to work properly in canary. 

This bug requires manual review: DEPS changes referenced in bugdroid comments.
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

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

approving for M72 branch: 3626

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

commit acf38d004ca4444484c138b4eecee94fabc62785
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri Dec 21 10:04:28 2018

[M72] Roll ICU to a26ec62

This is to cherry-pick two upstream CLs for Windows 7 timezone detection
to M72 branch. This cherry-pick has already been applied in M73/trunk
(https://crrev.com/c/1379250).

https://chromium.googlesource.com/chromium/deps/icu.git/+log/407b393..a26ec62

TBR=abdulsyed@chromium.org

Bug:  913298 
Test: See the bug.
Change-Id: I29b5caf057f0663b1330b5eee15c21261065edd3
Reviewed-on: https://chromium-review.googlesource.com/c/1388425
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#496}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/acf38d004ca4444484c138b4eecee94fabc62785/DEPS

Here's a summary of the rules that were executed: 
 - OnlyMergeApprovedChange: Rule Failed -- Revision acf38d004ca4444484c138b4eecee94fabc62785 was merged to refs/branch-heads/3626 branch with no merge approval from a TPM! 
Please explain why this change was merged to the branch!
 - AcknowledgeMerge: Notification Required -- 

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

Commit: acf38d004ca4444484c138b4eecee94fabc62785
Author: jshin@chromium.org
Commiter: jshin@chromium.org
Date: 2018-12-21 10:04:28 +0000 UTC

[M72] Roll ICU to a26ec62

This is to cherry-pick two upstream CLs for Windows 7 timezone detection
to M72 branch. This cherry-pick has already been applied in M73/trunk
(https://crrev.com/c/1379250).

https://chromium.googlesource.com/chromium/deps/icu.git/+log/407b393..a26ec62

TBR=abdulsyed@chromium.org

Bug:  913298 
Test: See the bug.
Change-Id: I29b5caf057f0663b1330b5eee15c21261065edd3
Reviewed-on: https://chromium-review.googlesource.com/c/1388425
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#496}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

> Revision acf38d004ca4444484c138b4eecee94fabc62785 was merged to refs/branch-heads/3626
> Please explain why this change was merged to the branch!

I think this is a false alarm. I did get the approval (see comment 66). 

I didn't want to include one unrelated CL in M73/trunk ICU committed before the two CLs to merge to ICU for M72. So, I can't merge M73 DEPS roll to M72 DEPS. Instead, I made chromium/m72 branch in ICU and cherry-picked the two CLs (basically 1-liner) in chromium/m72 branch.
Then, I rolled ICU in DEPS for M72 to the ToT in chromium/m72 branch. 

Fixed in M71, M72, M73. 

 Issue 919869  has been merged into this issue.

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

commit 3244d2df03b04d7ee70f579aea8d82c0498032ad
Author: Jungshik Shin <jshin@chromium.org>
Date: Thu Jan 10 18:54:27 2019

[M71] Roll ICU to 6939c541

The roll has 3 CLs.

The first reintroduces a fix for the timezone detection in remote
desktop connection on Windows (https://crbug.com/854387). It's
included in the first M71 stable release, but
was reverted in https://crrev.com/c/1370582 for the 2nd M71 release
as an emergency fix for  https://crbug.com/913298  .

The second and the third (combined) are a just 1-liner to fix
 https://crbug.com/913298   in a proper manner without regressiing
https://crbug.com/854387 .

https://chromium.googlesource.com/chromium/deps/icu.git/+log/751b643..6939c54

Bug: 854387,  913298 
Test: See the bug.
Change-Id: I6637898926341e3f0ca0268e5f381a813c786342
Reviewed-on: https://chromium-review.googlesource.com/c/1393338
Reviewed-by: Michael Moss <mmoss@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#930}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/3244d2df03b04d7ee70f579aea8d82c0498032ad/DEPS

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

Commit: 3244d2df03b04d7ee70f579aea8d82c0498032ad
Author: jshin@chromium.org
Commiter: jshin@chromium.org
Date: 2019-01-10 18:54:27 +0000 UTC

[M71] Roll ICU to 6939c541

The roll has 3 CLs.

The first reintroduces a fix for the timezone detection in remote
desktop connection on Windows (https://crbug.com/854387). It's
included in the first M71 stable release, but
was reverted in https://crrev.com/c/1370582 for the 2nd M71 release
as an emergency fix for  https://crbug.com/913298  .

The second and the third (combined) are a just 1-liner to fix
 https://crbug.com/913298   in a proper manner without regressiing
https://crbug.com/854387 .

https://chromium.googlesource.com/chromium/deps/icu.git/+log/751b643..6939c54

Bug: 854387,  913298 
Test: See the bug.
Change-Id: I6637898926341e3f0ca0268e5f381a813c786342
Reviewed-on: https://chromium-review.googlesource.com/c/1393338
Reviewed-by: Michael Moss <mmoss@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#930}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}