[Top][All Lists]

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

Re: [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time ret

From: Mark H Weaver
Subject: Re: [Bug-gnuzilla] JavaScript bug in Date class, incorrect date/time returned
Date: Thu, 20 Jun 2019 03:00:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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]