On 2021-04-29, Marfaba Stewart wrote:
> I'm confused about Firefox's handling of Date objects on OpenBSD.
>
> Why: Some Firefox browser extensions that display dates using
> Date.toLocaleString or Date.toLocaleDateString can cause an incorrect
> date to be displayed. For example, using a credit card expiration
> displayed as "01/23" when it really expires in February 2023 will make
> payments fail.
>
> Synopsis: Calling toLocaleString without parameters on a date object
> seems to yield the wrong time.
>
> Description: Calling toLocaleString without parameters yields a
> time that is one hour off for CST and two hours off for CDT. This
> seems to happen only on Firefox with OpenBSD -- not on Chromium on
> the same machine, nor on Firefox on other operating systems that
> I've tried.
>
> This problem will show up if you go to Web Developer -> Web Developer
> Tools and try any dates in the console.
>
> However, if you are in a Preferences tab and try it in the web
> developer console, the error will NOT show up.
>
> The error will also NOT show up if you use Date.toLocaleString
> within a regular web page.
>
> It only appears for me from the browser extension that uses
> Date.toLocaleString, and in the developer console from a tab that
> is not "Preferences."
>
> I think this is a Firefox bug and have reported it to Mozilla.
> I've reproduced the error on many OpenBSD machines for the last
> several months all running -current, with various version of Firefox,
> including 88.0.
>
> (My first attempt to get the source from ports failed because of
> an anemic machine, but I will try again with more memory.)
>
> Sadly, I've been banging my head against this problem for a long
> time. I initially and stupidly submitted to the wrong forum, and
> compounded the problem with an ill-formatted date, although I had
> tried valid dates as well. My example was unfortunate because, as
> far as I can tell, any date will generate this problem.
>
> My BIOS time is set to UTC and /etc/localtime points to US/Central.
> I've also tried changing the BIOS time to my local time and setting
> kern.utc_offset, but nothing changed.
>
> I also tried the Firefox option to use the operating system's setting
> to format dates just to see if that might affect anything, not
> expecting it to change anything. Indeed, nothing changed.
>
> As far as I can tell from reading developer.mozilla.org about
> Date and Date.prototype.toLocalString and international formats, etc.,
> calling toLocaleString without parameters might use an
> unpredictable format, but the time displayed should be local time.
>
> Some forum posts such as
>
> https://stackoverflow.com/questions/33083936/
> convert-date-to-local-time-zone-with-tolocalestring-method-firefox
>
> say this is a bug in Firefox.
>
> How-To-Repeat:
> From Web Developer -> Web Developer Tools in Firefox:
> (with input and output marked, and comments starting with #)
>
> # I've created the dates with new Date but
> # new Date(Date.UTC(.....)) doesn't change the results
> # of the call to toLocaleString
>
> # create date in Central Standard Time. so far so good
> INPUT: event1 = new Date(2021, 0, 1, 12, 0, 0)
> OUTPUT Date Fri Jan 01 2021 12:00:00 GMT-0600 (CST)
>
> # output below of toLocaleString() is one hour before local
> # time. Happens to match Canada/Mountain
>
> INPUT: event1.toLocaleString()
> OUTPUT: "1/1/2021, 11:00:00 AM"
>
> INPUT: event1.toLocaleString('en-US', {timeZone: "Canada/Mountain"})
> OUTPUT: "1/1/2021, 11:00:00 AM"
>
> INPUT: event1.toLocaleString('en-US', {timeZone: "US/Central"})
> OUTPUT: "1/1/2021, 12:00:00 PM"
>
> # create date in Central Daylight Time. so far so good
> INPUT: event2 = new Date(2021, 3, 29, 12, 0, 0);
> OUTPUT: Date Thu Apr 29 2021 12:00:00 GMT-0500 (CDT)
>
> # output below of toLocaleString()is two hours before local
> # time. Happens to match Canada/Pacific
>
> INPUT: event2.toLocaleString()
> OUTPUT: "4/29/2021, 10:00:00 AM"
>
> INPUT: event2.toLocaleString('en-US', {timeZone: "Canada/Pacific"})
> OUTPUT: "4/29/2021, 10:00:00 AM"
>
> INPUT: event2.toLocaleString('en-US', {timeZone: "US/Central"})
> OUTPUT: "4/29/2021, 12:00:00 PM"
>
> Fix: A workaround in the console: specify parameters to toLocaleString.
> To workaround the display problem in the browser extension, set
> privacy.resistfingerprinting to true. I think everything looks like
> UTC, so any conversion problems seem to go away.
I was troubleshooting a related issue in firefox 115.0.1 under OpenBSD
amd64/7.3-stable and confirmed the same issue you did with
Date.toLocaleString() being off by an hour. Fortunately, I found a
solution: ensuring TZ is set in the environment before launching firefox.
The original issue I found was that, despite local time being correct and
all other applications functioning correctly for years, firefox was
inconsistent about times, especially the local timezone, in JavaScript.
In terminal applications, I confirmed:
$ ls -al /etc/localtime
lrwxr-xr-x 1 root wheel 36 Sep 27 2022 /etc/localtime ->
/usr/share/zoneinfo/America/New_York
$ date
Thu Aug 3 18:57:55 EDT 2023
In the JavaScript console in chromium 111.0.5563.110 in the same xenodm
session:
> new Date().toString()
'Thu Aug 03 2023 19:00:33 GMT-0400 (Eastern Daylight Time)'
> new Date().getTimezoneOffset()
240
> Intl.DateTimeFormat().resolvedOptions().timeZone
'America/New_York'
> new Date().toLocaleString()
'8/3/2023, 7:11:54 PM'
However, in the firefox Javascript console (same xenodm session), I was
getting quite inconsistent results:
> new Date().toString()
"Thu Aug 03 2023 17:09:59 GMT-0600 (GMT-06:00)"
> new Date().getTimezoneOffset()
360
> Intl.DateTimeFormat().resolvedOptions().timeZone
"EST"
> new Date().toLocaleString()
"8/3/2023, 6:12:40 PM"
I don't run a desktop environment, just a fvwm-based window manager, and
don't export more than LC_CTYPE in my ~/.xsession (though I do have dbus
configured as described in /usr/local/share/doc/pkg-readmes/dbus.)
I wasted a bunch of time regarding suggestions of disabling
privacy.resistFingerprinting in firefox's about:config (it apparently
causes the time zone to always be UTC; but it was already disabled, in my
case). I also tried disabling related security settings in firefox to no
avail.
Finally, after digging into date/time-related manual pages, I decided to
give the following a try and it resolved all the issues:
$ TZ=/usr/share/zoneinfo/America/New_York firefox
I didn't find anything related TZ requirements in
/usr/local/share/doc/pkg-readmes/firefox. I thought maybe there was a
pledge issue, but I did confirm that my unmodified
/etc/firefox/pledge.socket contains the following line, so it should have
access:
rpath # at least for /etc/resolv.conf & /etc/localtime
I'm CC-ing ports@ and the firefox maintainer in case they want to dig into
the issue. Alternatively, I'm happy to submit a patch to the firefox
pkg-readme.
Morgan
