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