From https://listnr.corp.google.com/report/85499989814 :

Restarted google chrome last night; presumably triggering an update to the 
latest version (I rarely restart chrome or my PC, so updates are often a 
little late). Since then, websites like Whatsapp Web 
<https://cdn.discordapp.com/attachments/303807371132796928/456921846416146434/unknown.png> 
and Twitch.tv <https://pbs.twimg.com/media/DfrSOU-WAAAO8h-.jpg:large> and 
Facebook 
<https://cdn.discordapp.com/attachments/303807371132796928/456922793104375809/unknown.png> 
have incorrectly reported my time in timestamps. My time is correctly set 
in windows (and on my android phone, if this makes a difference) to GMT -4, 
with DST corrections disabled, as my country does not experience DST. My 
best guess is that since timestamps are 1 hour later, Chrome is forcing DST 
correction on my otherwise correct timezone. Incognito mode shows the same 
time discrepancy. Chrome is updated to the latest stable build, version 
67.0.3396.87 (Official

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

We need to find out how the user in the report sets the timezone. 

". My time is correctly set 
in windows (and on my android phone, if this makes a difference) to GMT -4, 
with DST corrections disabled, as my country does not experience DST."

Is there a way to ask the user what country he's in? There must be a better way to set the timezone for his country than setting it to UTC-4 and disabling DST. 

With that, there'd be no more problem. 

#2: Yup! That feedback report came from our community, so I've reached out to the user to ask their country. I'll update here when I hear back.

Thread for reference:
- https://productforums.google.com/forum/#!msg/chrome/qjXxPvr7Ze8/lWw5UU1fBQAJ

Thanks for taking a look, and for updating the components!

Not sure if this is the same issue or related (and I'm happy to file a separate bug for it), but 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.

josh@: can you file a separate bug and give me a pointer to your new bug here? 

Thanks


Thank you,  craigtumblison@ for reaching out in the community for my question. 

The user followed up to clarify:

> "I live in Trinidad and Tobago. We are always GMT-4, and never experience DST correction. This is why I alluded in my first post that it appears chrome is applying DST correction for me when it should not (I.E. making my time later than it is by one hour)."

I did some quick digging, and it seems like using a GMT-4 timezone on Windows and disabling DST adjustments may be a fairly common suggestion:

- https://answers.microsoft.com/en-us/windows/forum/windows_xp-desktop/what-time-zone-should-i-set-this-laptop-as-in-the/321d916f-e563-43dc-bb6d-f4e89cd1f437
- https://answers.microsoft.com/en-us/windows/forum/windows_7-performance/how-can-i-change-clock-settings-for-trinidad-and/3e49eb0d-2f45-4607-ac12-6d8a42614ca6

Thanks again for taking a look!

js: The new issue is 854387.

https://en.wikipedia.org/wiki/UTC%E2%88%9204:00#As_standard_time_(all_year_round)
lists places where UTC-4 is used year-round.  Users should pick one of those places in Windows timezone picker instead of picking UTC-4 and manually disabling DST. 

-------

Thank you, Josh. I'll take a look. 

#10: Hmm. That would work for this specific use case, but do we still want to look into why Chrome's time differs from the system time (i.e. is Chrome missing/ignoring the DST adjustment setting inappropriately)?

I'll reach back out to the user and share the advice re: selecting a year-round timezone as a best practice.

Thanks again!

> Hmm. That would work for this specific use case, but do we still want to look into why Chrome's time differs from the system time (i.e. is Chrome missing/ignoring the DST adjustment setting inappropriately)?

Chrome gets the windows time zone and converts that to IANA time zone ID. Manual DST switch is not a part of that conversion. 

That conversion does not take into account whether user turns OFF DST manually. 

IMHO, it's a bad idea for Windows to offer such a manual switch to start with.
I can't think of why users want to control DST in that way. They can always gets the correct time zone by selecting a time zone corresponding to their location (country/city, etc) unless Windows does not have any time zone choice corresponding to where they live. 

I don't think 'modern' Windows (Win 7 or later) has a very comprehensive time zone coverage. So, I suspect there's very little, if any, need for manual DST switch, which seems to be just a relic of the past. 
 

> I don't think 'modern' Windows (Win 7 or later) has a very comprehensive time zone coverage

I meant:  I think 'modern' Windows has a very comprehensive ....

> https://listnr.corp.google.com/report/85500625693

This is WAI. Users must have tried a year before the standard time zone was introduced. (say 1860 in Europe/Berlin )

> https://listnr.corp.google.com/product/237/report/85499423428

Again WAI. Same thing. Users tried year 1900/1899 before India began to have the standard time zone. 

> https://listnr.corp.google.com/product/237/report/85497266359

ditto 

> https://listnr.corp.google.com/product/237/report/85494270474

In 1928, there was NO DST. So, central time zone offset is UTC-0600 year-round. 
Again, wai. 


> https://listnr.corp.google.com/product/237/report/85484926926

This is a dupe of  bug 849724 . I have a CL to fix that pending review. 

> https://listnr.corp.google.com/product/237/report/85473981199

Again WAI. Chrome is reflecting the historical time zone offset changes while other browsers assume that the zone offset has not changed over time. 

Gotcha! Thanks so much for the explanation - it makes sense to me.

It sounds like this is working as intended from the Chrome side then, and we don't need to take any further action on this one.

I'll pass all this information along.

As per comment# 14, most of the cases seems to be WAI except for the bug:  849724 .

jshin@ Shall we mark this issue as duplicate of issue:  849724  ?

Thanks!