[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40765: [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/t

From: Ben Sturmfels
Subject: bug#40765: [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time returned
Date: Wed, 22 Apr 2020 22:18:51 +1000

One additional note that may help others diving into this issue. I found that disabling "privacy.resistFingerprinting" immediately changed the result of `new Date().toString()` on all tabs, but `new Date().getTimezoneOffset()` was changed only on the about:config tab. After a restart all tabs showed the correct offset.


"Wed Apr 22 2020 12:14:56 GMT+0000 (UTC)"
Hi Mark,

Thanks for responding.

It appears that this behavior is controlled by the privacy.resistFingerprinting option.
Setting it to false solves the problem on IceCat for the desktop,
but the problem persists on IceCatMobile (Android), regardless of the option. (Even after clearing the app's Android cache, browser cache, and restarting the app.)

However, if I understand correctly, the IceCat team no longer works on IceCatMobile.
The IceCatMobile bug tracker seems inactive, though.


On Thu, Jun 20, 2019 at 9:04 AM Mark H Weaver <address@hidden> wrote:

    Hi Jelle,

    Jelle Geerts <address@hidden> writes:

    > var s1 = new Date().toString();
    > var s2 = new Date().toLocaleString();
> var s3 = new Date().toLocaleString('nl', {'timeZone': 'Europe/Amsterdam'});
    > The resulting strings were:
    > s1 === 'Fri Jun 07 2019 13:58:32 GMT+0000 (UTC)'
    > s2 === '6/7/2019, 1:58:32 PM'
    > s3 === '7-6-2019 15:58:32'
    > s1 is not as expected (bug).
    > s2 is not as expected (bug).
    > s3 is as expected.
> Expected output (taken from Firefox; Chrome has the exact same output): > s1 === 'Fri Jun 07 2019 15:58:32 GMT+0200 (Central European Summer Time)'
    > s2 === '6/7/2019, 3:58:32 PM'
    > s3 === '7-6-2019 15:58:32'

    Yes, I've known about this issue for some time.

I strongly suspect that this difference in behavior is caused by one of the privacy-protecting changes that IceCat makes to Firefox 60 ESR's
    default settings, which are listed here:


For example, IceCat changes the default value of "geo.enabled" to false, to disable geolocation. If you think about it, revealing the user's local timezone to web sites via _javascript_ effectively allows a coarse
    form of geolocation.

If it's important to you to reveal your local timezone to web sites, I would suggest going into "about:config" and experimenting with reverting some of these IceCat configuration changes, starting with "geo.enabled".

If you could report back with your findings, that would be helpful,
    because you're not the first person to ask about this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]