1534160 - new Date() returning wrong timezone during DST on Android

Status: RESOLVED FIXED

(Core :: JavaScript: Internationalization API, defect)

Description

[danielbyron51]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

• Using newly installed Firefox 65.0.1 from the Google Play Store
• Connected USB debugger and ran in the console:

new Date().toString()

The problem also appears using websites that use new Date().

Actual results:

Results:

new Date().toString()
"Mon Mar 11 2019 08:52:29 GMT+1000 (GMT+10:00)"

Expected results:

The current time (and system time) is 9:52 Australian Eastern Daylight Time (GMT+11). The time returned by Firefox seems to be AEST (GMT+10).

I've tested this on two Android phones (Samsung A8 and Pixel) and the results were the same for both, the time is off by 1 hour.

It works correctly in other browsers on Android. It also works correctly with Firefox 65.0.2 on desktop.

Comment 1

[Stefan Deiac]

Hi, thanks for your report.
I tried to reproduce your issue on the latest version of Nightly 67.0a1 (2019-03-12) and Release 66.0 with Nexus 9 (Android 7.1.1), Google Pixel (Android 9) and OnePlus 5T (Android 9) using multiple links(w3schools.com, javascripture.com) but without any success.
Can you retry with a clear profile and make a video with your findings? You can record your screen using AZ Screen Recorder.
Also, please check your Date&time settings from device settings to be the proper one.
I'll wait for your updates, thanks.

Comment 2

[danielbyron51]

Hi Stefan,

I've taken two screenshots, one from a fresh installation of Firefox Nightly 67.0a1 (2019-03-13) and the other from Chrome, displaying the inconsistency between the two, and the inconsistency between Firefox and the system time (the actual time).

https://imgur.com/a/xmuBKHr

I made a screen recording as well but all the information is in those two screenshots, and the video only shows me opening the apps and pasting in the link I used to test the behaviour. If there's anything else I could provide or any info you'd be looking to see specifically please let me know.

My system settings are set to automatic date and time, with the date and time being set to the AEDT timezone. I also tried manually setting this time/timezone, force closing Firefox, reopening it and then trying again to the same result (time reported is AEST).

My Android version is 8. I've also tested it with a Pixel running Android 9.

Thanks for looking into this!

Comment 3

[Moongazer]

I can confirm this bug. I have created a webpage (address given below) with further details documenting the bug with screenshots and also demonstrating it. The page contains a clock. The clock shows the time 1 hour behind the current system time shown by Android, but it shows the correct time when viewed in Chrome browser on the same platform and also when viewed in other versions of Firefox, e.g. FF on Windows 7 and FF app on an iPhone running IOS.

To reproduce the bug, set your phone's timezone to Australian Eastern Daylight Time (Sydney, Canberra) (GMT+11) and view the website in Firefox app for Android and compare the time shown on the clock to the time displayed by Android. But do it before 03:00 on Sunday, April 7, 2019, because Daylight Saving Time ends then. (Or, if you try it after that time, you may be able to reproduce the bug by changing the system date to an earlier date.)

The webpage is http://moongazer.x10.mx/website/march/test/ (short URL: http://tiny.cc/androidffdstbug ).

Another tester has also confirmed the same bug, as reported in the reply by Reg to this thread on Whirlpool.

https://forums.whirlpool.net.au/thread/2793500&#bottom

Comment 4

[Moongazer]

(In reply to Stefan Deiac from comment #1)

"
I tried to reproduce your issue on the latest version of Nightly 67.0a1 (2019-03-12) and Release 66.0 with Nexus 9 (Android 7.1.1), Google Pixel (Android 9) and OnePlus 5T (Android 9) using multiple links(w3schools.com, javascripture.com) but without any success.
"

Stefan, in your testing, did you first set the timezone on the test device to Australian Eastern Daylight Time (Sydney. Canberra)? If the bug is caused by using an outdated Time Zone database with wrong Daylight Saving Time information for that locale, the bug would not be reproducible on a device set to a different locale for which the TZ database has correct information.

Comment 5

[Moongazer]

(In reply to Moongazer from comment #4)

Additional information: Although I have already posted a link to this source above, I thought it worthwhile to quote the following diagnostic information from the Web Development forum on the Australian Whirlpool site, which is strongly suggestive of what is causing this bug: Note: what he means by "as of today" is the date Friday, 5 April, 2019, on which DST is still in effect in several Australian states, but DST here (in those states) will end at 02:00, AEST (which is 03:00 AEDT) on the first Sunday in April, which is less than two days away.

From https://whrl.pl/Rflkyw :

"
That's definitely a bit of a head scratcher. If we just log:

Intl.DateTimeFormat().resolvedOptions().timeZone

It gives me a correct TZ identifier "Australia/Sydney" in Chrome for Android, but "Etc/GMT-10" on Firefox for Android (both Release and Nightly).

As of today, these refer to different time zone offsets.

I wonder why it does not realize that it is in a DST time zone. Does Firefox ship its own, incorrect tz database?
"

Comment 6

[Moongazer]

More information:

I was able this afternoon to again duplicate this bug on a more recent device than mine, running a much more recent version of Android. My friend's phone is a ONEPLUS 5 running OxygenOS ver 9.0.4. My friend opened my webpage at http://tiny.cc/androidffdstbug on her phone in Firefox for Android version 66.0.2. We were both able to observe the bug very much in evidence on that platform too. The time displayed on the clock was 1 hour earlier than the correct time, though, only a few minutes earlier, it displayed the correct time when the same webpage was opened in the Chrome web-browser on the same phone.

Comment 7

[Moongazer]

Daylight Saving Time here in Victoria, Australia ended on the first Sunday in April (2019-04-07). I am still able to reproduce this bug in Firefox on my Android phone by changing the date on my phone to April 5th (when DST was still in effect.)

Steps to reproduce:

1. Go to Settings/Date & time
2. If you are in Time Zone AEST (GMT+10) (Australia/Sydney) skip this step:
   (a) Switch off "Automatic time zone" to enable the setting "Select time zone"
   (b) Use the setting "Select time zone" to set the time zone to GMT+10, Australian Eastern Standard Time
3. If Daylight Saving Time is currently in effect, skip this step:
   (a) Switch off "Automatic Date & time" to enable "Set date"
   (b) Use the setting "Set date" to set the date to a date on which DST was in effect.
4. In Firefox, go to: http://tiny.cc/androidffdstbug
5. Observe whether the clock on that webpage is showing the same time as displayed by Android or is one hour behind.
6. Restore any Time Zone or Date setting you changed in 2 or 3 to their original values.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

waldo, should this fall under your Javascript:Internationalization component?

Comment 9

[Stefan Deiac]

I can reproduce this issue on the latest version of Nightly 68.0a1 (2019-04-23) using Google Pixel (Android 9) following the steps from comment 7.
Also, I found a regression range for this issue.

Last good revision: 9cef845a1039dc4ca84ead1240a7361049e4b60f
First bad revision: fd8d17192696250a5396894301478f36c6c75be7
Pushlog:https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9cef845a1039dc4ca84ead1240a7361049e4b60f&tochange=fd8d17192696250a5396894301478f36c6c75be7

Andre, this bug was regressed by 1346211(from pushlog). Can you take a look?

Comment 10

[André Bargull [:anba]]

As with bug 1540304, bug 1487594 should fix this time zone detection issue in ICU when running on Android.

Comment 11

[Moongazer]

(In reply to André Bargull [:anba] from comment #10)

Andre, some of us who read and comment here are humble content-developers, with nary a clue on writing, or contributing to development of, web browsers. We come here in search of ways of making our web-pages work as intended and making them platform-agnostic. For the benefit of us ignoramuses in your field, could you please clarify what you wrote in comment 10?

Are you suggesting that the cause of this bug lies in the use of ICU (perhaps due to incorrect data in the CLDR), which should be fixed there, or are you suggesting that using ICU is the solution to this bug? If the latter, is it a solution available only to the developers of Firefox, or is some of ICU's functionality also available to content-developers from, say, within a javascript function? The latter possibility seems unlikely to me, but if it is indeed possible, can you point me to information on how to use it?

Comment 12

[André Bargull [:anba]]

Sure. In bug 1346211, we've changed SpiderMonkey (Firefox' JavaScript engine) to use ICU to detect the current system time zone as part of moving all time zone handling to ICU. But nobody noticed at that time, that https://unicode-org.atlassian.net/browse/ICU-11992 resp. https://unicode-org.atlassian.net/browse/ICU-13208 will lead to detecting the wrong time zone on Android. Thankfully :m_kato recently proposed a patch for ICU https://github.com/unicode-org/icu/pull/605 to remedy this situation, so that we should probably get this fixed for Firefox 68. I currently don't have high hopes the pull request will be reviewed and accepted in time for Firefox 67, because there are only two work weeks left before the release. And if further adjustments to the pull request are necessary, this will probably happen after :m_kato's PTO (4/29-5/6).

From a web developer's point of view, there's isn't any workaround possible, at least as far as I know.

Comment 13

[Pascal Chevrel:pascalc]

Too late for 67, leaving as fix-optional in case a patch can be uplifted in a dot release.

Comment 14

[Nima]

I have Same the Problem with Firefox on Android 66.0.2 (Iran Daylight Time (IRDT - Iran Summer Time) TimeZone)
The time is displayed one hour behind.

---

<script>
var time=new Date().toString();
document.write (time);
</script>

Displays the wrong result on Firefox on Android (Result: Tue May 14 2019 11:25:20 GMT+0330)

But displays the correct result on Firefox 66.0.5 on windows 10 (Result: Tue May 14 2019 12:25:20 GMT+0430 (Iran Daylight Time)

Comment 15

[Brad Arant]

Tested on Samsung Note 8 in Pacific DST and shows correct -0700 zone and time.

Comment 16

[Nima]

Still having this problem with Firefox 67.0.3 on Android 8.0.0.
(Iran Daylight Time (IRDT - Iran Summer Time) TimeZone) The time is displayed one hour behind.

Comment 17

[Chris Peterson [:cpeterson]]

Does this time zone bug also affect the new Firefox Preview?

https://play.google.com/store/apps/details?id=org.mozilla.fenix

Comment 18

[André Bargull [:anba]]

Does this time zone bug also affect the new Firefox Preview?

Yes, that should be the case, because the underlying issue affects any application running on Android which is using ICU to detect the current system time zone.

Comment 19

[Chris Peterson [:cpeterson]]

(In reply to André Bargull [:anba] from comment #18)

Does this time zone bug also affect the new Firefox Preview?

Yes, that should be the case, because the underlying issue affects any application running on Android which is using ICU to detect the current system time zone.

Thanks. In that case, I will move this bug to the Bugzilla component for JavaScript Internationalization bugs.

Comment 20

[Moongazer]

Chris, if you are moving this thread elsewhere, could you please provide a link here to its new location?

Comment 21

[Chris Peterson [:cpeterson]]

(In reply to Moongazer from comment #20)

Chris, if you are moving this thread elsewhere, could you please provide a link here to its new location?

I only moved this bug report to a different Bugzilla category. I didn't move this bug discussion to a different bug report or mailing list. :)

Comment 22

[André Bargull [:anba]]

Hi :m_kato, did you get a chance to address the review feedback at https://github.com/unicode-org/icu/pull/605? Thanks!

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Following up on n-i in email with m_kato and waldo.

Comment 24

[Makoto Kato [:m_kato]]

(In reply to André Bargull [:anba] from comment #22)

Hi :m_kato, did you get a chance to address the review feedback at https://github.com/unicode-org/icu/pull/605? Thanks!

Ah, github mail is gone to spam box. I will look it today.

Comment 26

[Pascal Chevrel:pascalc]

Makoto, could you provide a status update on this bug? Thanks

Comment 27

[Makoto Kato [:m_kato]]

(In reply to Pascal Chevrel:pascalc from comment #26)

Makoto, could you provide a status update on this bug? Thanks

I need update ICU patch since Google's android team requests that they want to use new async API. So I need update fix (for ICU)

Comment 28

[Pascal Chevrel:pascalc]

Too late for 71.

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

We may want to track this as it's been a problem for several releases. We could still get a patch in for 73/Fennec 68.45.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

I'd be open to a low-risk fix, but I don't see a need to track this either.

Comment 32

[Quent]

Hi,
I agree that it would be nice to ship some fix. I tried installing Firefox Beta for Android but it seems to have the same version 68.6 as the Standard Firefox for Android (as of 17/03/2020 00:29 AEDT).
At least that if it gets included in the next pre-release, there's a chance for it to be on everyone's mobile before the next Australian bushfires :/
Thanks in advance.

Comment 35

[André Bargull [:anba]]

Attachment: Bug 1534160 - Part 1: Re-run ICU updater to pick up latest changes to ICU 67 maintenance branch. r=jwalden!

The change itself isn't important for us, because we don't use ICU's make-files,
but avoids confusion why additional changes were applied when running the update
script.

Comment 36

[André Bargull [:anba]]

Attachment: Bug 1534160 - Part 2: Cherry-pick patch for Android time zone detection. r=jwalden!

Cherry-pick the commit from https://github.com/unicode-org/icu/pull/605.

Depends on D82545

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9eb33f647439
Part 1: Re-run ICU updater to pick up latest changes to ICU 67 maintenance branch. r=jwalden
https://hg.mozilla.org/integration/autoland/rev/6c8547a37a63
Part 2: Cherry-pick patch for Android time zone detection. r=jwalden

Comment 38

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/9eb33f647439
https://hg.mozilla.org/mozilla-central/rev/6c8547a37a63

Comment 39

[Moongazer]

Well, it's good to know that a fix has at last been found for this bug, but where do we get Firefox80 for Android? The latest push update that I got from Google Play Store installed Firefox 68.10.1 which seems a long way behind Firefox80. So how long is it likely to be before we get Firefox80?

Comment 40

[André Bargull [:anba]]

@Moongazer
The new Firefox browser for Android will contain this fix. You probably have this Firefox version installed, which is based on the (previous) Firefox ESR release and only receives security fixes at this point, but no longer any new features. The new Firefox browser for Android is currently in Beta, but the fix is currently only available for Nightly builds (resp. it will include the fix when that build picks up the latest changes from https://hg.mozilla.org/mozilla-central/).

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Did we want to nominate this for Beta uplift for 79?

Comment 42

[André Bargull [:anba]]

I'd first like to verify this actually works as expected. (When I tried this a few hours ago, I still got the wrong time zone, but I'm not sure how frequently the Android Nightly is updated resp. how fast changes from m-central appear on Android Nightly.)

Comment 43

[Ryan VanderMeulen [:RyanVM]]

The latest-available Firefox Nightly build from the Play Store has a GV build from 2020-07-08, so things indeed seem to be lagging behind a bit.

Comment 44

[Ryan VanderMeulen [:RyanVM]]

Fenix Nightly should have the fix now if you want to try verifying again.

Comment 45

[Quent]

I can confirm the fix works for me on Nightly 200714 06:01 (Build #21960614) GV: 80.0a1-20200111092223
My time zone is automatically set to Australia/Sydney. I disabled "Automatic date and time", set a date in early February to be in GMT+11 Australian Eastern Daylight Time.
I opened the current Firefox (68.10.1) and could reproduce the issue (one hour shift).
I loaded a page with the new Date() on the Nightly above and the time was correct.
Thanks heaps.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Probably best to let this fix ride the 80 train instead of doing a last-minute uplift.

Comment 47

[André Bargull [:anba]]

Yes, bug 1653333 made it quite obvious we don't want an uplift.