Sorry this last worked in 66. Typo :-(

Thank you, Josh, for the bug report. 

From  bug 854253  comment 6:

--------
we're having timezone issues with many of our users who span multiple timezones. Our users run Chrome in a Citrix XenApp session (think Remote Desktop Session Host - many users, one server) and Chrome seems to be grabbing the timezone from the system's console rather than the timezone of the user.
---------

Chrome (ICU used by Chrome) reads the time zone information from the following registry: 

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Perhaps, it has to read it from 'per-user' registry ?  

Jack:  do you know what registry ICU should use instead ?  I'd ask Jeff but I don't know his email address. I may have to file a follow-up bug to http://bugs.icu-project.org/trac/ticket/13826 . 

Filed: http://bugs.icu-project.org/trac/ticket/13842

For what it's worth, I'm not sure if this information is stored in the registry. I searched and couldn't find anything that was per user. I'm guessing it would have to be queried somehow from the OS.

One more thing to clarify, the time zone for the user is being set by the RDP client using Time Zone Redirection. The user isn't setting the Time Zone manually through the Control Panel.

I can't say I know too much about this part of Windows, but Jeff's email is jefgen@microsoft.com (I *also* don't know much about monorail so I don't know how to actually Cc him in the thread).

Thank you, Jack and Josh. Jeff replied in the ICU ticket I filed (comment 6). 
There's no per-user time zone and neither is a separate registry entry (e.g. in HKCU). 
According to Jeff, the way to fix that is to use a Windows API instead of reading the registry directly. 

Josh, in the meantime, you can use the following command line flag to Chrome: 

--js-flags="--no-icu-timezone-data"

Would it be a viable work-around for your users? 

Thank you for the quick turn around. What does that flag do? Is there a way to globally apply it? Otherwise I can probably modify the main shortcut our users use to launch Chrome, but my concern is that there may be other ways they are launch it that might not catch that flag (other shortcuts to Chrome that they have created, shortcuts to URLs, clicking a URL in their e-mail application, etc).

Lastly, is there a proposed timeframe for this change? If not that's ok, I just need to keep management updated on this.

That flag disables using ICU for timezone handling. So, it restores the old behavior at the cost of not working properly for timezones that have undergone offset changes. All timezones have changed their offset (if we go back far enough to the past), but some timezone have changed the offset/DST rules rather recently (even multiple times since 2000; e.g. Europe/Moscow). 

I don't know yet how to resolve the ICU bug mentioned above. So, it may not be fixed before long. 

Thanks. We're going to wait another month and see where things are at then.

We have a customer reporting same issue. 
They are using RDP
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName shows UTC and so does Chrome, although all other browsers show user timezone.

Adding --js-flags="--no-icu-timezone-data" doesn't seem to help.

I've another customer:
case#: 16659046
Chrome version: 68.0.3440.84
server version: Windows 2012 R2 Standard
remote connector: citrix
they have this setting https://screenshot.googleplex.com/UWXOi4cQQ6k in the citrix configuration
local PC registry HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName = "Singapore Standard Time"
remote session registry HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName = "AUS Eastern Standard Time"
using the flag --js-flags="--no-icu-timezone-data" solved the issue.

is there any progress on this issue ?

Looks like ICU has corrected this: https://github.com/unicode-org/icu/pull/55

ICU issue was fixed in the upstream. [1] Next ICU update will be October. So, unless I cherry-pick the upstream change now, this will remain broken until Chrome 72 whose stable release will be out in next January. 

Hmm... that's a bit far away. I'll take a look if I can cherry-pick the upstream CL.   


[1]  https://unicode-org.atlassian.net/browse/ICU-13842

jshin@
Are we still planning to fix it on Chrome 72?

 Issue 891206  has been merged into this issue.

Sorry I should have cherry-picked the upstream fix sooner. Let me do it now so that at least M71 will get it.  Then, we'll see what we can do with M70. 

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

commit ccad4472126e35ccd1d19bea38b6675802d40472
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Oct 09 08:17:32 2018

Fix the timezone detection on Windows with RDP.

This is to cherry-pick fixes from the upstream to fix
the timezone detection issue when a remote Windows
session is used. The detected timezone should be that of
a remote machine Chrome is running on, but without this
fix, it uses the timezone of machine where a RDP connection
originates.

Bugs:

https://unicode-org.atlassian.net/browse/ICU-13842
https://unicode-org.atlassian.net/browse/ICU-13827

Fixes (included in the upstream ICU 63 release candidate)
https://github.com/unicode-org/icu/pull/55
https://github.com/unicode-org/icu/pull/129

TBR=yangguo@chromium.org
Bug: 854387
Test: Manual. See the bug
Change-Id: Ic21e82987c1569e107d9b5e17bdc0d21e65fda3c
Reviewed-on: https://chromium-review.googlesource.com/c/1270635
Reviewed-by: Jungshik Shin <jshin@chromium.org>

[modify] https://crrev.com/ccad4472126e35ccd1d19bea38b6675802d40472/README.chromium
[add] https://crrev.com/ccad4472126e35ccd1d19bea38b6675802d40472/patches/wintz_detection.patch
[modify] https://crrev.com/ccad4472126e35ccd1d19bea38b6675802d40472/source/common/putil.cpp
[modify] https://crrev.com/ccad4472126e35ccd1d19bea38b6675802d40472/source/common/wintz.cpp
[modify] https://crrev.com/ccad4472126e35ccd1d19bea38b6675802d40472/source/common/wintz.h

Thanks for the Help.

Does this mean that "RDP/citrix remote session timezone setting" issue will be sure solved in Chrome 71, and maybe with Chrome 70 ?

That means we will have to stop the chrome automatic updating process through GPO policy, and keep Chrome version 68 until bug is solved.

Regards,
David.

Hi,

Yes, it will be fixed for sure in 71 and if the patch is accepted for merge into 70 already there (I can't tell if this will be possible so late in the release process at this point). If you prefer to skip 69 doing so with Google Update's GPO is indeed the best way.

Best,
Julian

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

commit fec152acbf487c58de34152b7f4e641b790d83c8
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Oct 09 15:47:36 2018

Roll ICU to ccad447

This roll has one CL in ICU to fix the Windows timezone
detection in Windows remote desktop connection.

https://chromium.googlesource.com/chromium/deps/icu/+/ccad447

TBR=yangguo@chromium.org

Bug: 854387
Test: Manual. See the bug.
Change-Id: I792e68bedaa6065d8d9886aa3ef5c15988f1d43e
Reviewed-on: https://chromium-review.googlesource.com/c/1270520
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597925}
[modify] https://crrev.com/fec152acbf487c58de34152b7f4e641b790d83c8/DEPS

requesting merge to 70.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

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

Thanks Guyz'

Hope fix will be available in Chrome Version 70.

regards,
David.

jshin@ how safe is this merge overall? Have you verified this locally?

Chatted with jshin@ this isn't ready to be merged yet, since it hasn't been verified yet. 

This should be in canary tomorrow. David.pauchet@ can you please help us verify the fix tomorrow in canary?

Do we really want to merge in M70 so late? I'd rather hold off until M71. This isn't a new regression to be pressing enough to patch in so late.

I didn't ask for merge, but merge-review was automatically requested by bot. :-) 

At least, I want to wait for user-test results with canary.   Per comment 32, testing with canary build would be appreciated. Thanks !

Agreed - this is present for quite a few milestones. Let's target 71.

Jayhlee@ is there more urgency for this for M70?

Hello,

We succesfully tested the "--js-flags="--no-icu-timezone-data"" into the chrome command line with Version 69.

So we're now able to upgrade ou PVS Vdisk, and publish Chrome V69 to our worldwide users.

Hope this command line will work either with chrome V70, waiting for the bug fix in V71. can you validate it ?

I will do the test in V70 canary asap, and will give you the result.

Regards,
David.

Hi,
Just added a printscreen with Chrome process published on the same server, one with option ""--js-flags="--no-icu-timezone-data", and one without.

Option temporary solves the issue.

Will now test with Canary V70, without the command line for ICU-timezone.

Deleted: Chromev69_CmdLine_ICU.jpg 495 KB

	Chromev69_CmdLine_ICU.jpg 495 KB View Download

Hello all,

I get some troubles to publish the Chrome Canary version on a RDS/Citrix server.
The canary version is installed by default into the user profile which installs the app. "c:\Users\xxxxxxxxx\AppData\Local\Google\Chrome SxS\Application\chrome.exe".

This path is not accessible to other users, because of acls, so app cannot be published.

Is there a way to install the chrome canary version in another directory than the user profile directory ?
May i copy "chrome sxs" folder in "C:\Program Files (x86)\Google\Chrome sxs\" folder, in order to make it accessible to all users, and be published ?

Regards,
David.

Thank you for testing, David. The js-flags should work with Chrome 70 as well. 

As for deploying canary to all users, I'm not sure how to. What you wrote in comment 38 may or may not work. (Google search found a couple of questions along the line, but no definitive answer was found). 


Given that the js-flag works as a work-around (well, with that, other bugs will manifest that were fixed by using ICU), targeting 71 instead of 70 seems ok. Moreover, the size of the patch to ICU is a bit large (I'm dependent on the upstream doing the right thing - the patch was from Windows engineers and Windows these days does include ICU).

jayhlee@:  Do you have a lot of complaints from enterprise users on this issue? (sorry that I didn't realize that you asked for m-70 merge review). Would it work to tell them to use the js-flag above (comment 37)? 

BTW, https://chromium-review.googlesource.com/c/v8/v8/+/1270924 shows that v8 trunk is happy with the change (as far as tests run on trybots are concerned). 

> Will now test with Canary V70, without the command line for ICU-timezone.

It has to be Chrome 71.x (canary) instead of 70. And, you may want to grab the latest canary late today in US PDT, UTC-7 (= early Thursday in UTC). 

Thanks,

I will wait latest canary version v71, and try to publish it on a RDS/citrix server in remote user session.

Will bring you the result asap.

Regards,
David.

Hello all.
Sorry for the testing delay.

I just tested with Chrome Canary 72, and Timezone issue does not appear anymore.

WSo i ill keep the js-flag "--no-icu-timezone-data" until Chrome V72 final version will be available.

Thanks for the help, and issue solving.

Regards,
David.

Deleted: Chrome_Canary72_Timezone.jpg 160 KB

	Chrome_Canary72_Timezone.jpg 160 KB View Download

Thank you for testing. It looks like Canary already moved to 72.x (it would have been 71.x last week :-) ).  71.x should have this fix as well. 

 Issue 901656  has been merged into this issue.

 Issue 902091  has been merged into this issue.

 Issue 876296  has been merged into this issue.

 Issue 908310  has been merged into this issue.

Hi Team,

I just want to know if the fix will be roll out for v70 also? Or it will be available at stable v71+?

Thanks in advance!

Hi all,

Tested with latest v71 just released ( 71.0.3578.80 Official Build ), and Timezone is OK in RDS mode without the ""--js-flags="--no-icu-timezone-data" parameter in the command line.

Chrome Timezone is now the user RDS session timezone.

Thanks for helping & resolving this issue.
David.

David,

Thanks for testing and confirming! This is awesome!

Thanks to everyone who helped get this resolved.

Many thanks for turning this around quickly, much appreciated!

Steve.

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

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}

Hello all,

RDS timezone issue seems to be corrected with latest version 71.

But i get now an issue with my australian users timezone, with 1hour difference between v68 time and v71 ICU time !

Need to rollback one more time to Chrome V68, latest well known version without timezone issues in RDS/ICA mode.

RDS Timezone Issue is back in the chrome version v71.0.3578.98 !!
on RDS/Citrix server, timezone should be the user computer timezone but is the rds server console timezone !

I thought it was OK in the chrome v71.0.3578.80 version, but there is an issue with the new ICU timezone for exemple for my australian users ..

Please find printscreen in the doc. attached

Deleted: Chome_Timezone_v68_v71.doc 357 KB

Chome_Timezone_v68_v71.doc 357 KB Download

Based on #54 and #55, this seems like it needs more investigation. Jungshik, Frank, can you ptal?

Hello all,

I made more tests this morning to try to understand what's going on.
Seems the Timezone issue occurs with Chrome 32Bits, not with Chrome 64Bits.

Whe a user is connected to a RDS/Citrix server, the user session timezone has to be the user local workstation timezone.
It's OK in other Browsers, like IE or Firefox, but seems problematic into Chrome since ICU timezone implementing in chrome v69...

One solution to solve the issue is to desactivate the new "ICU" timezone mode, with setting "--js-flags=--no-icu-timezone-data" in the chrome process start command line.

But would be better to solde that issue without the need of that "--js-flags=--no-icu-timezone-data parameter !!


Please find printscreens in the doc attached.


To resume :
Chrome 64Bits
71.0.3578.80   Timezone OK for australian users with or without “js-flags=--no-icu-timezone-data”.
71.0.3578.98   ?  need to make more tests.

Chrome 32Bits
71.0.3578.98 32Bits   « ICU » Timezone not OK at all.  Chrome Timezone is the RDS/citrix server timezone, instead of the user computer timezone !!
71.0.3578.80 32Bits   « ICU » Timezone OK for European Users, but not OK  for Australian users ( 1Hour difference ! )
68.0.3440.106 32Bits  No ICU ..  Timezone ok for all users

Can the ICU timezone issue be solved quickly ?

Regards,
David.

Deleted: Chome_Timezone_v68_v71_20181214.doc 662 KB

Chome_Timezone_v68_v71_20181214.doc 662 KB Download

It's back in M71 because M71 needs an emergency fix to deal with  bug 913298 .  Sorry about that. It's an unfortunate trade-off. 

Note that the CL description recorded in comment 53 explicitly mentioned that it'd regress this bug. 


A better fix for  bug 913298  has been developed since. It's basically a 1-liner. So, it would be possible to get it merged to M71 if  there is going to be another M71 release.  

Ok, thanks.

We 'll have to wait for the new version, hoping that new fix will definitly solve those Timezones issues in Chrome when in a RDS/Citrix user session.

Will the "js-flags=--no-icu-timezone-data" parameter will continue to be available in the next versions ?

Regards,
David.

M71 still has that flag. 

https://chromium-review.googlesource.com/c/chromium/src/+/1379250 is a fix for  bug 913298  . Once it's tested on m72 and m73, the revert recorded in comment 73 can be reverted to bring baxk in a fix for this bug in m71, on top of which the fix for  bug 913298  can be merged to m71.

Ok, thanks.

So, still have to use ""js-flags=--no-icu-timezone-data" flag for now on my win2008R2 RDS/Citrix servers to avoid the timezone issue.

Waiting for the Bug Fix.

Regards,
David.

 Issue 914809  has been merged into this issue.

When is this expected to be fixed? Is it fixed in 72 and w're just waiting for that to go stable?

re: comment 63

It was fixed in early October in M71 branch and the fix was included in the first stable release of M71 (early Dec), but had to be reverted to deal with  bug 913298  (see comment 53).  So, the second stable release of M71 does not have the fix. 

In the meantime, M72 and M73 have a fix for  bug 913298  as well as a fix for this bug. 

https://bugs.chromium.org/p/chromium/issues/detail?id=854387  is a new CL to deps-roll ICU in M71 branch to include the original fix for this bug and an upstream fix (1-line change) for  bug 913298 . 

Asking for merge to M71 (if there's gonna be yet another spin on M71 stable). 

As mentioned above and in the CL description:  this should be safe; 

The fix for this bug was tested in M71 branch before the revert (comment 53: it's reverted for  bug 913298 ). The fix for  bug 913298  is very simple and has been tested on Windows 7 in M72 and M73 branches. 

Ooops. The CL link in comment 64 is wrong. I meant this :

https://chromium-review.googlesource.com/c/chromium/src/+/1393338/

At the moment, there is no plan for M71 respin. Lets wait on lower channels coverage and we can consider this fix for next M71 respin (if any)

Approving merge to M71 branch 3578 based on comment #64 and per internal mail thread. Pls merge so we can pick it up for next M71 respin (if any). Thank you.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

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}