IssueTracker

Please fix this!!!. We have quite a few apps that cannot use GCM because of this.

This should have a "high" priority, not a "medium" priority. The reason being that you cannot change the package name for apps already deployed to the app store. This means that any apps that have already been deployed with upper case package name are unable to use GCM. :-(

This goes back to an issue with C2DM.  It did not allow the package name permission to start with a capital letter either.  Since Android allows the package name to start with a capital letter, this permission should be able to as well.

Here is the excerpt from android package name documentation :

http://developer.android.com/guide/topics/manifest/manifest-element.html

"A full Java-language-style package name for the application. The name should be unique. The name may contain uppercase or lowercase letters ('A' through 'Z'), numbers, and underscores ('_'). However, individual package name parts may only start with letters."

Upper case letters should be ok.

After doing a little more digging, the original post has the best description in the correct behavior.  Currently ANY permission must not begin with a capital letter if and only if there is a dot operator inside of it.  Permissions should be able to be created with capitalized names.

Isn't there a way to do this yet?

It's really anoying for everyone, users and developers, to do a new app just for this issue

news ?

DO AGREE...the same requirements as for Java package name should be used for permissions!

결론이 난건가요?

Any Update on this?
I need this feature too.
if the App is already in Store with the packagename "Myapplication.com" and you rename this Line: <permission android:name="myapplication.com.permission.C2D_MESSAGE" android:protectionLevel="signature" /> to a lower case letter, then it will work, but only for Devices with Android 4+.

Please fix this!

You probably cannot fix this retroactively for devices that are already running non-supporting versions of Android, since there's no way to force an update in general.  So to me it seems that the fix would be for the GP store to allow apps to rename their packages on an update from mixed case to all lower case, so long as nothing else changes and so long as there was not already another app with the resulting lower-case name.  The store, being in the cloud, can fix this for almost everyone (except some very unfortunate hypothetical person who decided to have two apps with package names only distinguished by case).  That should handle 99.9 percent of the cases.

This bug has been marked as obsolete but there is no resolution provided.

still opened and still no solution to this after years.

Jeeeeeeez this is such a weird bug.

[Empty comment from Monorail migration]

Ok, I will ask the customers to provide the information requested in https://crbug.com/chromium/1168528#c12. There is also a report that the problem resolved after the Windows time zone setting was changed to another area and then returned to the original setting.

The build is ICU 68.1 but with patch of https://github.com/unicode-org/icu/pull/1465 

Unable to reproduce the issue on windows-10 using chrome reported version #88.0.4324.96.
Steps followed
=============
1. Opened chrome browser having version #87.0.4280.88
2. Navigated to System Settings
3. Changed  "Region"-> Tokyo
4. Changed "Date and Time"->(UTC+09.00) Osaka,Sapporo,Tokyo
6. Updated Chrome to latest stable #88.0.4324.96(chrome://settings/help)
Observed that system date/time and Chrome time stamp(gmail, chrome://history) are matching.

Note: Also tried with (Moscow +3:00 UTC) timestamp

Attaching screen cast for reference
Also attaching the Windows system configuration details

Thanks...!

[Empty comment from Monorail migration]

Also the issue is not reproducible on the Windows-10 systems having the below configurations.
1. Windows 10 Pro 1909, OS build: 18363.1256
2. Windows 10 Home Single Language 2004, OS build: 19041.685
3. Windows 10 Enterprise  10.0.18363

Hey all,

Following up to confirm that we have reached out to 12 users for additional information. We specifically asked for their Window computer's time zone, whether automatic DST was enabled, their configured region, and whether they are using any remote connection technology. We included a link to this bug, and I will also monitor our outreach tool for any responses.

Outreach comms (Google-internal, apologies):
- https://docs.google.com/document/d/1BJApLZISF2d80eQ0ucv_Wc3I5n__kiDffgfeAbo9Obw/edit#

Additionally, we have new feedback reports from users in the Philippines and Taiwan. These were included in our outreach.
- https://listnr.corp.google.com/report/88175416847
- https://listnr.corp.google.com/report/88175268969

Lastly, we have an additional confirmation to match https://crbug.com/chromium/1168528#c16. A user in one of our community forum threads has confirmed that switching to a new time zone, then restoring the old one appears to resolve the behavior.
- https://support.google.com/chrome/thread/94287601?msgid=94413298

Thanks!

Following up, we have heard back from two users. Please find their answers below.

What is your Windows computer’s time zone?
User 1: (UTC-03:00) Brasília
User 2: This was not answered.

Does your Windows computer have automatic daylight saving time enabled?
User 1: Daylight saving time is no longer used in Brazil, and in my Windows computer, this options is disabled.
User 2: User indicated this option was not enabled.

Which country or region is your Windows device configured to use?
User 1: Brazil
User 2: Brazil

Are you using your Windows device directly, or are you connected remotely using another computer?
User 1: Directly using device.
User 2: User indicates they are directly using the device.

Note: Some answers have been tweaked slightly to preserve anonymity.

I will continue to monitor for additional responses.

[Empty comment from Monorail migration]

Frank and Jeff,  I just skimmed over this bug. Do we have a fix (or at least a partial fix) in the ICU trunk?  

If so,  Frank, why don't you port the patch over to the Chromium's ICU and ask for merge to M88?  

So,  the fix applied to Chromium's ICU trunk (https://crbug.com/chromium/1168528#c6) is not yet in the ICU for Chromium 88 branch, is it?  
Frank, why don't you merge it to ICU for Chromium 68 branch?  

Thank you jshin@.

Re #25, Frank, why don't you merge it to ICU for Chromium 68 branch?  You mean Chromium 88 branch, right?

This CL was merged to M88 here - https://chromium-review.googlesource.com/c/chromium/src/+/2555542

> Frank, why don't you merge it to ICU for Chromium 68 branch?

I meant, 88 branch.

I was told that the first fix was already merged to 88 branch. Sorry for the noise.

Jeff, thanks.a lot for fixing a bug introduced by me .

However, https://unicode-org.atlassian.net/browse/ICU-21465 is still outstanding.

> I was told that the first fix was already merged to 88 branch. Sorry for the noise.
And, that's not for this bug but for https://crbug.com/chromium/1147305 .  Sorry again for the confusion.

Re: https://crbug.com/chromium/1168528#c21 and https://crbug.com/chromium/1168528#c22

Thank you kindly for the info!

I can't access the Google Docs link in https://crbug.com/chromium/1168528#c21 with the comms, but I did try to reproduce using the same configuration that was noted in https://crbug.com/chromium/1168528#c22 from the users.

Unfortunately, I wasn't able to reproduce the issue though. (Attached screenshot for reference).

Re: https://crbug.com/chromium/1168528#c29
> Jeff, thanks.a lot for fixing a bug introduced by me .
> However, https://unicode-org.atlassian.net/browse/ICU-21465 is still outstanding.

No worries about the bug! Thank you very kindly for your PRs -- it was great to be able to collaborate with you!
About ICU-21465: Yes, the bug was filed just yesterday, and so far I have not been able to reproduce the issue, which makes it hard to investigate...

Regarding this:
> A user in one of our community forum threads has confirmed that switching to a new time zone, then restoring the old one appears to resolve the behavior.

That is a rather interesting observation. It makes me wonder if somehow the settings on the computer are in a corrupted or invalid state, and changing the time zone to something else, and then back again fixes or restores the settings.

I wonder what might be corrupted or invalid though... I wonder also if we might need to harden ICU against bad settings in Windows, but as of yet I'm not sure what might be causing it.

We are still holding M88 release at 10% for windows platform due to this issue.

We had a sync today , we think this issue might not be wide spread and as per https://crbug.com/chromium/1168528#c16 we might have a workaroud to get this working. Mac/Linux platforms using the same ICU version dont have problems. We are waiting for enterprise support team to let  us know if the enterprise cases in https://crbug.com/chromium/1168528#c13 are resolved. and if they feel good for us to ramp up to 25%. allanrobert@, mshibahara@. We would also like to collect more traces/logs that would help with the investigation from the enterprise users if we can do a outreach to them

allanrobert@ any update on the feedback from enterprise users if the work around works for them? also any info on information requested in https://crbug.com/chromium/1168528#c12 for further helping with investigation

Hey all,

We heard back from one additional user over, please find their answers below.

What is your Windows computer’s time zone?
- (UTC + 09: 00) Osaka, Sapporo, Tokyo

Does your Windows computer have automatic daylight saving time enabled?
- Off

Which country or region is your Windows device configured to use?
- Japan

The user also confirmed that the workaround (changing time zone) resolved the issue for them.

In terms of feedback volume, we've seen a drop-off in new reports so far today, but it is now the weekend in Japan, so this may be expected.

Thanks!

Hi srinivassista@,  craigtumblison@,

we have reached out to the customers yesterday but we haven't heard from them so far.
we are still confirming the following points:
1) Understand if the workaround about changing windows timezones from one timezone to another is a valid way to solve this issue for all the customers

2) Provide the items detailed in comments crbug/1168528#c12 to ENG for customers affected by this issue
Let me also update the bug

If there were no workaround at all, I would expect our Enterprise customers to be more responsive (this would have already been massively escalated due to the business impact). Therefore, the workaround about changing timezones at windows level (detailed in https://crbug.com/chromium/1168528#c16 and https://crbug.com/chromium/1168528#c34) should probably be valid.


"In terms of feedback volume, we've seen a drop-off in new reports so far today, but it is now the weekend in Japan, so this may be expected."
>>> We will follow up on Monday JST (Sunday PDT)

Thanks for the updates and for the info in https://crbug.com/chromium/1168528#c34.

Unfortunately I'm still not able to reproduce the issue locally.
I've tried using the various settings that are reported (for JP and BR), and neither of them repro the issue.

Given the various comments that a work-around is to change from one Windows time zone to another, and then back again, I am suspecting that there is some kind of "invalid" state with the original Windows time zone setting on the PCs that are reporting this issue.

In order to try and help with debugging, I've create a test program that dumps out the various Windows time zone info from the Win32 APIs, and uploaded it as an attachment. The program is named "OutputTimeZone.exe".

I've test signed the executable, and also signed it with my PGP key as well (see the attached .asc file).

Note: The Visual Studio Redist is needed in order to run the program, from: https://support.microsoft.com/en-us/help/2977003
(I can also create a statically linked version as well, if this is an issue.).

Perhaps it is a bit of a long shot -- but if possible, could the output from the OutputTimeZone program be collected from a machine with the issue?

This would help to narrow down exactly what possible invalid/corrupted state might be reported by the Win32 API(s), in order to try and find some hardening or work-around within the ICU code.

Thanks!

[Empty comment from Monorail migration]

Out of the 15 Japanese cases that are currently assigned to Google Cloud Support:
-> The issue has been fixed with the workaround at windows timezone level : 7 cases
-> Information about the workaround Provided, WOCA : 2 cases
-> Confirming if the workaround worked or not, WOCR: 6 cases

Two of our resellers informed us that this issue has been fixed by lasted version 88.0.4324.104.
They did not apply the workaround about changing the timezone at windows level. They said that this issue disappeared just by using the latest chrome version.
Is there any new update for the fix?

Based on our sync - here is our next steps. 1) Based on the updates on the bug in comments #38 and #39 , and not high feedback seen we are proceeding with ramp up of windows to 25% today. 2) we will re-sync tomororow to figure out next ramp up. but at this point this does not seem severe enough to block the roll out. 3) For any enterprise users hitting this issue , please help run steps in https://crbug.com/chromium/1168528#c36 before applying the workaround so we can get more data for debugging and fixing the issue.

so we know there are some issue with timezone in m88 originally. and later a fix went into m88 to fix it
https://chromium.googlesource.com/chromium/src/+/c5bd345afa5626186dd75a70e258abcb6890fd88

Is there a way to check that is not in 88.0.4324.96  but IS in 88.0.4324.104?  

The CL in https://crbug.com/chromium/1168528#c41 landed in 88.0.4324.17 so it was part of M88,

Regarding the fix working in buld 88.0.4324.104 , there are no code changes between build 88.0.4324.96 and 104, it was just a installer change that was picked up in build 104 to fix a MSI install issue. We created a mini branch off of build 96 and got build 104 so they are identical from code base perspective.

maybe related issue : https://bugs.chromium.org/p/chromium/issues/detail?id=1154099

Thank you very kindly for the screenshot in https://crbug.com/chromium/1168528#c37 with the output from the OutputTimeZone.exe program!

This has been very helpful in finally getting an understanding of what is going on…

I believe there are actually two issues here:

1. Incorrect/invalid data from the Win32 API GetDynamicTimeZoneInformation.
2. The calculated value for the offset when the Automatic DST setting is OFF.

For the first issue:

Looking at the screenshot in https://crbug.com/chromium/1168528#c37, the results from the OutputTimeZone.exe program are very odd. The DynamicDaylightTimeDisabled value should not be 1, it should be 0.
This is only supposed to be 1 if the user turned off Automatic DST in the CPL. However, for "Russian Standard Time" there is no DST, so this should be 0. This means that the results from the Win32 API GetDynamicTimeZoneInformation is actually wrong and/or invalid.
For this issue, I don't think that ICU or Chrome are necessarily at fault here, as the Win32 API is returning wrong/incorrect data. Rather, they are the victims of bad data. (This is also indicated by the reports that changing the time zone to something else, and then back again fixes the wrong value).

It took a long time, but I was finally able to reproduce this locally in a VM, after manually editing the registry to change the value of DynamicDaylightTimeDisabled, and then rebooting. (In other words, I had to manually corrupt the data in order to get it to reproduce). I attached a screenshot below [Win7-repro-of-bug.png] which shows the issue repro'ing on a Win7 VM.

Since this only seems to happen when incorrect data is returned by GetDynamicTimeZoneInformation, that might explain why the issue isn't hitting many users, and/or seems somewhat random.

One other additional point about this being wrong/bad data, is that if you use the Windows built-in command line tool "tzutil" to output the current time zone, it also is confused about the setting as well.

The command "tzutil /g" shows the current time zone ID. In this "bad" or corrupted state it will output the (incorrect) result of "Russian Standard Time_dstoff". The correct result should be "Russian Standard Time" instead. (Note the extra "_dstoff" on the end). In other words, even the built in Windows tools are confused – so I don't know how ICU/Chrome can fare much better in this state. :(

As for why this would be impacting ICU/Chrome now: In ICU 68 changes were made to handle the case when a user turns off the "Automatic DST" setting in the CPL. We could possibly revert these changes (which would fix this "bug") -- but that would regress or re-open this bug instead: https://bugs.chromium.org/p/chromium/issues/detail?id=854201


Which leads to the second issue:

The offset value for the calculated time zone when the Automatic DST setting is Off seems to be wrong. The sign for the time zone offset is flipped. (It’s positive when it should be negative, and vice-versa).
I think this was perhaps due to confusion about the value for the UTC offset, how POSIX style offsets are handled, and what is reported by the Win32 API GetDynamicTimeZoneInformation.

(The issue was actually present in the original PR here: https://github.com/unicode-org/icu/pull/1297/files, and it was missed in the reviews on the other PR here: https://github.com/unicode-org/icu/pull/1362 ).
I missed this when I was manually testing out the changes, as I was expecting the wrong values for the offset (Ex: Etc/GMT-8 instead of Etc/GMT+8).

The good news is that I think the fix for this second issue is rather simple, and I plan on opening a PR for the upstream ICU project shortly. (The change can hopefully be cherry-picked once merged).

However, I don’t know of any way to fix the first issue with the Win32 API GetDynamicTimeZoneInformation returning bad data.

I'm not sure how we can handle both of these cases at the same time:
- The "Automatic DST" setting being OFF in the CPL.
- Wrong/incorrect data from the Win32 API GetDynamicTimeZoneInformation.

However, that said, if the second issue is fixed then at least the numerical time should still be correct, even if the actual time zone ID itself will technically be wrong.

FYI, I created a PR for the second issue in https://crbug.com/chromium/1168528#c44 here:
https://github.com/unicode-org/icu/pull/1539

Jeff- thanks for working on this. Really appreciate. The major concern of taking this fix (either in ICU or in Chrome) right now is how could we QA this issue. If we somehow have a reliable testing procedure could reproduce the problem before/after the fix then I will feel more comfortable.

Try to understand a little bit more-
1. Is the bug only show up when BOTH https://crbug.com/chromium/1 (the wrong data return by API) AND 2 (Auto DST turn off) happen? or do we have TWO bugs which either one will cause the problem.

2. Is issue #1 fixed by some microsoft OS patch already? or not?
3. If we do not have issue #1 in the machine, is there a reliable test procedure that we can reproduce the bug apply your patch in pull 1539 and verify the fix after 1539? If so, could you write down step by step?

Update per our sync at 9am ,

We will proceed with M88 ramp up to 100% and not block the ramp up for this bug.

In parallel ftang@ will try to repro the issue based on steps that jeff shares and we will try to evaluate the feasibility of the patch to merge to M88 or M89

craig/team will help post the workaround on the forums so users get visibility on the work around for each of the impacted regions.

Hi everyone,

With the information of https://crbug.com/chromium/1168528#c44, it was very easy to reproduce the issue.
Try the following steps:
 - Change windows time zone to some time zone where can exists summer timer time, for instance, (America/Santiago).
        - Intl.DateTimeFormat().resolvedOptions().timeZone
                - Chrome 87:
                        -> "America/Santiago"
                - Chrome 88:
                        -> "America/Santiago"
 - Disable "Automatic change DST" option on Windows (America/Santiago).
        - Intl.DateTimeFormat().resolvedOptions().timeZone
                - Chrome 87:
                        -> "America/Santiago"
                - Chrome 88:
                        -> "Etc/GMT-4"
                                - We have the wrong time zone value, it should be "Etc/GMT+4" in this TZ format.

In my opinion this bug is very critical, every windows computer with automatic DST setting disabled will be affected.
For instance, I work with hospital systems and we have critical situations here with wrong dates because of this bug.

I think is not a good idea proceed with M88 ramp up without fixed this issue.

madigo@ is the work around suggested not working for you?

From https://crbug.com/chromium/1168528#c46:
> If we somehow have a reliable testing procedure could reproduce the problem before/after the fix then I will feel more comfortable.

Thanks Frank, I've created a document that has different manual test cases that exercise various scenarios for most of the code paths for the Windows TZ mapping in ICU. (I also added notes on what the various test cases are exercising in the code.)
Here's a link: https://docs.google.com/document/d/17Y_Ns4EBV8wnHioJNFc-dJCRRpJ3hpJZDYmTq6ekIsM

The Test case 7 in that document reproduces the issue; with the fix the correct result of `Etc/GMT-10` should be reported back from the `icuinfo.exe` tool. I used this to validate the changes in the PR for the second issue.

> 1. Is the bug only show up when BOTH https://crbug.com/chromium/1 (the wrong data return by API) AND 2 (Auto DST turn off) happen? or do we have TWO bugs which either one will cause the problem.

Sorry if the https://crbug.com/chromium/1168528#c44 wasn't clear perhaps. I believe there are two separate issues here: (1) is the wrong data from the API, and (2) the offset is wrong when the Automatic DST setting is OFF.

The first issue occurring leads to the second issue being hit. However, it isn't necessary for issue (1) to occur in order to hit issue (2). The second issue would effect anyone that has set the "Automatic DST" setting to be OFF in the Control Panel, and also anyone with issue (1), as it leads to the same code path being taken.

However, the second issue would occur for any time zone that has a non-zero offset, and it also wouldn't matter if it was during daylight saving time or not.

> 2. Is issue #1 fixed by some microsoft OS patch already? or not?
I'm not sure what is causing the first issue though. It could be random corruption perhaps, or possibly even some third party software that changes settings, etc.-- so I'm not sure what is the cause of the issue and/or if there is any patch or not.

> 3. If we do not have issue #1 in the machine, is there a reliable test procedure that we can reproduce the bug apply your patch in pull 1539 and verify the fix after 1539? If so, could you write down step by step?

Yes, you can disable the Automatic DST setting for any time zone with a non-zero offset and it will reproduce the issue. In the document linked above I added screenshots that show how to do this for testing in order to very the fix.

I was able to replicate the issue as per #48. But the behavior is buggy in M88 and in older chrome versions with Time Zone UTC-4.00 and above(Worked well until UTC-3.00)

Steps followed
--------------
1. Windows settings-> Date and Time settings
2. Time zone -> UTC-4.00(Santiago) (Notice the time change in system clock)
3. Adjust Daylight saving -> OFF
4. Navigate to any webpage in chrome
5. chrome://history
6. Check system time with chrome time

Observed
---------
1. In M88: System date and time is off by many hrs(See screenshot)
2. In M87, M86, M85 : System time is off by an hr, so guessing it went unnoticed. (See screenshot)

OS: Windows 10 Pro, OS build : 19041.746

We're seeing a good number of reports with this on Brave too; seems to be ICU has different time zone than system

Reported with https://github.com/brave/brave-browser/issues/13669 and more details in https://community.brave.com/t/my-brave-is-showing-the-wrong-time/197973/7

Some time zones of affected users:
- Brazil / Buenos Aires (GMT-3)
- Hong Kong (GMT+8)
- Uruguay (GMT-3)
- Japan (GMT+9)

Users are reporting a work-around which might help shed light on the root cause:
> To everyone having this problem. I changed my windows timezone to some random one and then again my actual timezone and it fixed this error. Try it.

Several users report this fixes the problem for them

About #51
"2. In M87, M86, M85 : System time is off by an hr, so guessing it went unnoticed. (See screenshot)"
That is because you turn the  daylight saving time  OFF on the system but the actual time is still under daylight saving time.

ok. so the bug is reproduce-able under the following condition
1.  Windows AND
2. User "3. Adjust Daylight saving -> OFF

Users who live in a timezone which observe daylight saving time will probably less likely to do #2 because that means all their application will have incorrect time. Probably that is why we see that in users in Japan now (since Japan does not observe Daylight Saving time, therefore if the users turn that OFF the users already see a lot of wrong time from other places.

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

commit 2eefd9a18a2084e02b12691a60ff932f82cfb385
Author: Frank Tang <ftang@chromium.org>
Date: Tue Jan 26 23:14:57 2021

CP Windows TZ fix for DST off

upstream PR https://github.com/unicode-org/icu/pull/1539

Bug: 1168528
Change-Id: I118919e0140ce96c4b8a6f5d308d7e2d8584a1d6
TBR: jshin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2649148
Reviewed-by: Frank Tang <ftang@chromium.org>

[modify] https://crrev.com/2eefd9a18a2084e02b12691a60ff932f82cfb385/source/common/wintz.cpp
[add] https://crrev.com/2eefd9a18a2084e02b12691a60ff932f82cfb385/patches/wintz2.patch
[modify] https://crrev.com/2eefd9a18a2084e02b12691a60ff932f82cfb385/README.chromium

ok, here is the plan
1. I will cp the fix from ICU into m90 trunk tonight
2. on Th (Jan 28), if we can verify on a windows machine which m88 m89 still show the problem but the trunk fix the problem, I will propose to cp that into m89
3. now the thing is a little bit complicated for m88 since we already land several other fix of ICU into m89 before this. and we need to decide if we only want to cp this fix into m88 but not others, we may need to branch off icu from the the commit last landed on m88 just for this. but let's address #1 and #2 first.


From my understanding of the issue, the bug should NOT appear for any users ENABLE Automatic Daylight Saving time and only impact users who DISABLE the Automatic Daylight Saving time. Also this is for sure a Windows only bug and will NOT impact Mac/Linux/ChromeOS/Android.

Re: https://crbug.com/chromium/1168528#c55: Thank you very much Frank. I appreciate all your work on this.

> the bug should NOT appear for any users ENABLE Automatic Daylight Saving time and only impact users who DISABLE the Automatic Daylight Saving time. Also this is for sure a Windows only bug and will NOT impact Mac/Linux/ChromeOS/Android.

Yes, that is my understanding as well -- but with the extra added complication of the issue (1) [wrong data from the API], causing it to *appear* as though Automatic Daylight Saving is set to DISABLED, when it really it not.

> if we can verify on a windows machine which m88 m89 still show the problem but the trunk fix the problem

I can try to help out with this. If you can provide download links for the builds then I can try testing them out on windows machines to see if the fix resolves the issue.

Hello,

About https://crbug.com/chromium/1168528#c49:
The workaround works, for while, we send an urgent communication for our
customers to downgrade the Chrome version or change the time zone on all
Windows computers.
For us, the worst is the scale to apply this workaround.
We have thousands of customers (Hospitals) in Brazil, Japan and many other
countries and each customer can have thousands of computers where the
workaround needs to be applied.

However, the main situation here is the amount of wrong data that can be
generated because of this bug in too many systems without people having
noticed it yet.

About https://crbug.com/chromium/1168528#c51.

"2. In M87, M86, M85 : System time is off by an hr, so guessing it went
unnoticed. (See screenshot)"
The reason for this is that in versions before M88 the time zone returned
always the same value, even with the "automatic DST" setting turned on or
not.
Therefore, The DST will keep being applied because the time zone ID
returned is still the same (America/Santiago), resulting in one hour
difference from Windows clock.

Actually, when this issue was fixed unfortunately generated this new
situation, how is shown in https://crbug.com/chromium/1168528#c44

About https://crbug.com/chromium/1168528#c55 and #56

Some countries like Brazil usually have too many changes in time zone
rules, especially on DST rules, for instance, Brazil has had different
summer time rules in 2018, 2019 and 2020 (DST is no longer in use).
Because of this, it was common that some users disabled automatic DST
adjustment if their computers did not have the last DST rules applied when
DST was starting or ending.

This does not explain why there is wrong data on Windows, but can explain
why some countries were more affected than others.
(Maybe just someone forgot to clear this data on Windows update for Brazil
DST change)

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

commit f4b07d711b0e3548a02deb8c40e859197fd04434
Author: Frank Tang <ftang@chromium.org>
Date: Wed Jan 27 16:00:07 2021

Roll ICU to fix TimeZone problem on Win

https://chromium.googlesource.com/chromium/deps/icu.git/+log/899e18..2eefd9a

TBR=jshin@chromium.org

Bug: 1168528
Change-Id: I170e24e01e6386e8ddc86a7dd4d3019dc2bf134c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2651450
Reviewed-by: Frank Tang <ftang@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#847634}

[modify] https://crrev.com/f4b07d711b0e3548a02deb8c40e859197fd04434/DEPS

ok, I start to land the fix into trunk. Once that get into the nightly build I will post here and Jeff and other who have window machine can try to verify the fix.

I am merging the CL in https://crbug.com/chromium/1168528#c58 to canary branch :4400 and will trigger a new canary build now so we can get early verification of the fix.

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

commit 5756a423c0e96040b017b97ed5613845faf739dc
Author: Frank Tang <ftang@chromium.org>
Date: Wed Jan 27 18:07:15 2021

Roll ICU to fix TimeZone problem on Win

https://chromium.googlesource.com/chromium/deps/icu.git/+log/899e18..2eefd9a

TBR=jshin@chromium.org

(cherry picked from commit f4b07d711b0e3548a02deb8c40e859197fd04434)

Bug: 1168528
Change-Id: I170e24e01e6386e8ddc86a7dd4d3019dc2bf134c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2651450
Reviewed-by: Frank Tang <ftang@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#847634}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2653712
Reviewed-by: Srinivas Sista <srinivassista@chromium.org>
Commit-Queue: Srinivas Sista <srinivassista@chromium.org>
Cr-Commit-Position: refs/branch-heads/4400@{#7}
Cr-Branched-From: 9a77f9773e6577bbd1bab31ba5d468159a7db9e7-refs/heads/master@{#846900}

[modify] https://crrev.com/5756a423c0e96040b017b97ed5613845faf739dc/DEPS

90.0.4400.5 is in queue and should be available in next 2-3 hrs on canary for verification

[Empty comment from Monorail migration]

Switching to a new time zone, then restoring the old one appears to resolve the behavior.

Able to reproduce the issue on chrome reported version #88.0.4324.96 as per https://crbug.com/chromium/1168528#c51 on windows-10.

Verified the fix on windows-10 using latest M-90 #90.0.4400.8
Attaching screenshots for reference.
Observed that chrome time syncs with the system time using different time zone settings as below:
Time zone -> UTC-4.00(Santiago)
Daylight saving -> OFF

Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

Jeff, could you download the canary build from
https://www.google.com/chrome/canary/ (the build number should be >= 90.0.4400.5)
and verify the fix

[Empty comment from Monorail migration]

merge into 89 should be easy since m89 already have other ICU changes.

[Empty comment from Monorail migration]

This bug requires manual review: DEPS changes referenced in bugdroid comments.
Before a merge request will be considered, the following information is required to be added to this bug:

1. Does your merge fit within the Merge Decision Guidelines?
- Chrome: https://chromium.googlesource.com/chromium/src.git/+/master/docs/process/merge_request.md#when-to-request-a-merge
- Chrome OS: https://goto.google.com/cros-release-branch-merge-guidelines
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on ToT?
4. Does this change need to be merged into other active release branches (M-1, M+1)?
5. Why are these changes required in this milestone after branch?
6. Is this a new feature?
7. If it is a new feature, is it behind a flag using finch?

Chrome OS Only:
8. Was the change reviewed and approved by the Eng Prod Representative? See Eng Prod ownership by component: http://go/cros-engprodcomponents

Please contact the milestone owner if you have questions.
Owners: benmason@(Android), bindusuvarna@(iOS), geohsu@(ChromeOS), pbommana@(Desktop)

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

for m88, I created M88 branch on ICU repo base on the hash 6a33b647c0647c3eb97eae5432153ef2dfca7baa
https://chromium.googlesource.com/chromium/deps/icu.git/+/refs/heads/chromium/m88 

6a33b647c0647c3eb97eae5432153ef2dfca7baa is currently used in https://chromium.googlesource.com/chromium/src/+/refs/tags/88.0.4324.139/DEPS

The cherrypick CL is https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2657048
Once that land into icu.git/+/refs/heads/chromium/m88

I will prepare a CL for m88

Re https://crbug.com/chromium/1168528#c66: Thanks Frank!
I downloaded the Chrome Canary build (>= 90.0.4400.5) and tested it on 3 different versions of Windows:

- Windows 7 Version 6.1 Build 7601 SP1
- Windows 10 Version 1909 Build 18363.1316
- Windows 10 Version 20H2 Build 19042.746

The fix works on all three versions that I tested, with different time zones set in the Control Panel.

In the attached screenshots I did a comparison of Chrome Dev/Beta versus the Chrome Canary with the fix.
You can see the correct time is now shown in the History page, and also by the output from "new Date();" in the Dev Console window.

m89 CP CL https://chromium-review.googlesource.com/c/chromium/src/+/2657189 (waiting for merge approval for m89)

For m89 reviewers- Please notice this bug is already build on Canary and verify fix in #90.0.4400.8 by  krajshree@chromium.org 

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

commit d1e2bd28c490a92d410c8014b68527941e124212
Author: Frank Tang <ftang@chromium.org>
Date: Thu Jan 28 21:47:15 2021

[M88] CP Windows TZ fix for DST off

upstream PR https://github.com/unicode-org/icu/pull/1539

Bug: 1168528
Change-Id: I118919e0140ce96c4b8a6f5d308d7e2d8584a1d6
TBR: jshin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2649148
Reviewed-by: Frank Tang <ftang@chromium.org>
(cherry picked from commit 2eefd9a18a2084e02b12691a60ff932f82cfb385)
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2657048
Reviewed-by: Jungshik Shin <jshin@chromium.org>

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

CL for m88 https://chromium-review.googlesource.com/c/chromium/src/+/2657838

remove "merge-merged-m88" since https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2657048 is only changing ICU branch and we still need to land  https://chromium-review.googlesource.com/c/chromium/src/+/2657838 to merge the effect into m88

Waiting for approval of Merge-Request-88

Jeff from Microsoft also confirm the fix on the following machines

"
Jeff Genovy 12:51 (2 hours ago)
to srinivassista@google.com, me, jefgen.msft@gmail.com, jshin@chromium.org, sffc@google.com, cira@google.com, mscherer@google.com

Thanks Frank,


I downloaded the Chrome Canary build (> 90.0.4400) and tested it on 3 different versions of Windows:

 

- Windows 7 Version 6.1 -- Build 7601 SP1

- Windows 10 Version 1909 -- Build 18363.1316

- Windows 10 Version 20H2 -- Build 19042.746

 

The fix works on all three versions that I tested, with different time zones set in the Control Panel. 😊

In the attached screenshots I did a comparison of Chrome Dev/Beta versus the Chrome Canary with the fix. You can see the correct time is now shown in the History page and also by the output from "new Date();" in the Dev Console window.

"

Jeff confirm he can reproduce the bug on 3 windows from 89.0.4389.23 and verify the fix in 90.0.4400

Merge approved for M88 branch:4324 please merge before Friday 12pm PST

[Empty comment from Monorail migration]

Removing Needs-Bisect label as per https://crbug.com/chromium/1168528#c61.

Thanks...!!

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

commit 7478f4db8009e9a02754669e29c97f704e966e81
Author: Frank Tang <ftang@chromium.org>
Date: Fri Jan 29 17:49:46 2021

[m88] CP ICU TZ fix

https://chromium.googlesource.com/chromium/deps/icu.git/+log/6a33b64..d1e2bd2

Bug: 1168528, 854201
Change-Id: I2ca24ccd8e324babb963a126a387c868bb3abf98
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2657838
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/branch-heads/4324@{#2063}
Cr-Branched-From: c73b5a651d37a6c4d0b8e3262cc4015a5579c6c8-refs/heads/master@{#827102}

[modify] https://crrev.com/7478f4db8009e9a02754669e29c97f704e966e81/DEPS

Approving the change to M89 Branch : 4389, Please go ahead and merge the CL to branch 4389 (refs/branch-heads/4389) manually, So that the change would be picked as part of next week's Beta release.

Hi,
I really appreciate the help for everyone who is behind working to resolve this.

May I know if this is already resolved?
And when is the update going to be available?

The reason I asked is that we have a booking system and based on our estimates, we have over 2000+ people affected by this bug.

It would be great to get some updates so we can also make our system-wide notifications.

Thank you in advance!

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

commit a1af633783f53caacc9f07e963027aa4f8c2297d
Author: Frank Tang <ftang@chromium.org>
Date: Sun Jan 31 07:47:13 2021

[m89] Roll ICU to fix TimeZone problem on Win

https://chromium.googlesource.com/chromium/deps/icu.git/+log/899e18..2eefd9a

TBR=jshin@chromium.org

(cherry picked from commit f4b07d711b0e3548a02deb8c40e859197fd04434)

Bug: 1168528
Change-Id: I170e24e01e6386e8ddc86a7dd4d3019dc2bf134c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2651450
Reviewed-by: Frank Tang <ftang@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#847634}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2657189
Cr-Commit-Position: refs/branch-heads/4389@{#442}
Cr-Branched-From: 9251c5db2b6d5a59fe4eac7aafa5fed37c139bb7-refs/heads/master@{#843830}

[modify] https://crrev.com/a1af633783f53caacc9f07e963027aa4f8c2297d/DEPS

I'm the person who reported the https://crbug.com/chromium/854201 about the DST off issue. There seems to be a timestamp problem (+10 hours) with the Gmail messages since the  DST off bug was fixed in Chrome 88. I'm in the New York TZ and my DST is off. (Chrome Version 88.0.4324.104 (Official Build) (64-bit))

Do I need to start a New Issue?

This message and the one above have a +10 hours timestamp (sent this message at 09:05 am)

I can conform that by setting the Daylight Saving Time on will clear this +10hours. So DST OFF not respected https://crbug.com/chromium/854201 is NOT FIXED. The issue has different effects. My DST is on. I sent this message 0841am. And see 8:41 AM EST

DST is off. Message time is 6:42 PM GMT+5 (just now)

Until now, the only way I managed to solve this on my clients (Brazil), was manually editing the registry as following:

DynamicDaylightTimeDisabled from 1 to 0 via regedit. But then I had to manually set the time for one hour behind, also.

The funny thing is, I started to see some other Brazilians reporting that if we change the timezone for another city that doesn't have accentuation, the problem solvs.

So for example, I simulated this in one of my clients:

Original Timezone City with accentuation: Brasília GMT -3  
New Timezone City: Salvador GMT -3

After doing this and whithout messing up with DynamicDaylightTimeDisabled settings, the problem was solved

Go figure!

the fix is merged to release branch , and in terms of roll out of the new build for M88, we are working towards getting out a build early this week, Will keep you posted once it is ready and available on stable channnel

Thanks. In the meanwhile, I've suggested my clients go back to Chrome Version 87.0.4280.66 (Official Build) (64-bit) which has no problems with "DST off" not being respected.

when you report there are still issue, could you please in every comment also report with the version of Chrome it show the problem. For m88, m89, and m90, each of them have SOME build with fix and some build without fix, so unless you also report a detail version number with every one of your report, it is very very difficult for us to figure out you are testing on a build without our fix or with our fix.

All my comments are based on the Chrome Version 88.0.4324.104 (Official Build) (64-bit)
There's an obvious flow to conversation which doesn't require a repeat of version every single comment.

[Comment Deleted]

Also hit this issue on chrome verion 88.0.4324.104

Currently my local TZ is UTC+8, but the browser shows UTC-8.

It corrupts my calender app, Meetingroom management system, Grafana monitoring panel .etc

W/R is to switch local TZ  and change back. （on each os reboot.）

Verified the fix on windows-10 using latest M-88 #88.0.4324.146
Attaching screenshot for reference.
Observed that chrome time syncs with the system time using different time zone settings as below:
Time zone -> UTC-4.00(Santiago)
Daylight saving -> OFF

Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

[Empty comment from Monorail migration]

That's nice and all. People working on TZ & time for Chrome need to be reminded to check vs DST off. Otherwise the same shoot will happen. Seriously, guys & gals: How long will you keep rehearsing the DST off https://crbug.com/chromium/854201 ???

I won't change this until I'm good & happy that Chrome's done their homework. So that's Chrome Version 87.0.4280.66 eveyone out there

just updated and it seems ok

88.0.4324.146 (Build ufficiale) (a 64 bit)

Thanks for confirming, Yes the build with the fix M88.0.4324.146 is now pushing to stable channel for win, Please upgrade and confirm the issue is fixed.

Upgrade to  88.0.4324.146 done, Chrome restarted. Fixed.

Well, that's what Frank Tang said way back when on https://crbug.com/chromium/854201. Let me be dubious & wait for your coding teams to acknowledge the DST off bug on every one of their upgrade for a long good while. Then I'll suggest my clients to install your latest. Until then: Chrome Version 87.0.4280.66 is the tang!

BTW: Happy Groundhog Day to all the "official" & "unofficial" Chrome teams... ♫ I Got You Babe ♫

madigo@ thanks for sharing the great steps in https://crbug.com/chromium/1168528#c48 - those work perfectly to reproduce issue / verify fix 🎉
Copied / modified those steps to the Brave issue for verification
https://github.com/brave/brave-browser/issues/13669

Verified the fix on windows-10 using latest M-89 #89.0.4389.40
Attaching screenshot for reference.
Observed that chrome time syncs with the system time using different time zone settings as below:
Time zone -> UTC-4.00(Santiago)
Daylight saving -> OFF

Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

Well done guys.
It's working on 88.0.4324.146.

Thanks.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Thanks Jeff from Microsoft for fixing this issue quickly. The credit is all his, I am just communicating and cherrypicking/merging his patch :)

[Empty comment from Monorail migration]

Once again a Fixed status by Frank Tang!?!
How long will that last?
Just to get this right, the link https://bugs.chromium.org/p/chromium/issues/detail?id=1168528#c112 places me to https://crbug.com/chromium/1168528#c97. (-15 positioning)
Get your shoot right Google / Chrome !!!
- Your Friendly Neighbourhood Spiderbug
♫ Spiderbug, Spiderbug... ♫

[Empty comment from Monorail migration]

This is not correct. https://crbug.com/chromium/1175803 is not about time being off but rather a currency matter when in the same country that your currency is. If you buy things in Canada and your currency is Canadian dollars, your currency shouldn't show $2.25 CAD. Get your flipping stuff straight & please don't assign Indians or Asians to North American problems. I know squat about India, Asia. As they know squat about NA issues.
-yours truly
A tired user of Chrome who needs their employees to do their job correctly

ftang@ can you please help create a post mortem for this issue , go/crpm has process details

Hi guys, i'm facing the same problem again. Chrome 96.0.4664.110 PT-BR. All configurations seem correct but there are differences between the application (Zimbra Mail) and how Chrome shows the received mail appointment.

Hey tommi...@gmail.com good luck with those idiots man. I fought them over 2 years and it's a guy from Microsoft who gave 'em  the solution. They can't test their code to save their lives. Nowadays, it's put out your code and we'll correct it later: long gone the days when you had to buy your software at a physical store like that Crazy Harry (Montreal)

This issue was migrated from crbug.com/chromium/1168528?no_tracker_redirect=1

[Auto-CCs applied]
[Monorail mergedwith: crbug.com/chromium/1169325, crbug.com/chromium/1171582, crbug.com/chromium/1171740, crbug.com/chromium/1173867, crbug.com/chromium/1175803]
[Monorail components added to Component Tags custom field.]

Я имею проблему, что после смены часового пояса, время макбука показывает 08:33, время хром показывает 09:33.
В Алматы, Казахстан недавно произошла смена часового пояса, с +6 на +5.
Версия 122.0.6261.112