Hi, "new Date().getTimezoneOffset()" should return a whole number and because it does not with firefox (any version) on freebsd12-stable or current, it will break some functionality with sites that use this when creating a JSON that gets sanitised before it's accepted by the site. Tested from desktop installation with addons, firefox 79.0,1 built in 12-stable r363045 via poudriere Tested on vm installation freebsd-current r363183 firefox 79.0,1 from official freebsd pkgsite Tested as above this time with firefox-esr-68.11.0,1 steps to reproduce: 1. open a javascript console in firefox 2. enter "new Date().getTimezoneOffset()" without the quotes 3. ctrl+enter 4. result should be a whole number 5. result in firefox is -59.55 6. result with firefox-esr is the same as regular firefox Same test with iridium from same machine gives -60 as expected. Timezone is Europe/London. Same test from firefox on linux mint 18.2 gives 0
Can't reproduce with firefox 79.0,1 on 12-stable r363465. Check that your system time, or the time you're trying to convert in Firefox, isn't somehow set to a value before 1847. (show the exact output of the "new Date()" call.) The timezone db regards the timezone offset for London before 1847 to be -00:01:15 (based on the difference between solar time at Kew Observatory and that at Greenwich). Did you set the timezone via the TZ environment variable (and regardless, is this variable set and to what value), or via tzsetup installing an /etc/localtime file? If the latter, what happens if you use TZ=Europe/London in the environment?
(In reply to andrew from comment #1) Hi, Exact output (from Firefox) of new Date(): Date Wed Jul 29 2020 03:18:27 GMT+0059 (BST) output of date (from tcsh) a few minutes later is Wed 29 Jul 2020 03:25:52 BST output of new Date() from iridium a little while later: Wed Jul 29 2020 03:35:42 GMT+0100 (British Summer Time) when both this system and the 13-current vm system was set up, the timezone was set to Europe/London I ran tzsetup directly just now, then did the new Date() thing and it's not making a difference. As far as I can see, I'm not setting TZ from any rc files. I use tcsh. I'm baffled why the timezone shows as GMT+0059 in firefox yet GMT+0100 in iridium on the same machine, or why it would show GMT+0059 in a vanilla firefox on a new 13-current vm on different hardware in a different geographical location. ntpd runs on both machines, and the time is correct in each case. If from tcsh I do: setenv TZ Europe/London then firefox & I'll still get the GMT+0059 it's very odd.
If (on firefox) I do new Date(0) result is: Date Thu Jan 01 1970 01:00:00 GMT+0100 (BST) so there the offset is correct maybe a javascript problem in firefox?
In firefox again: new Date('1971-10-31'); Date Sun Oct 31 1971 01:00:00 GMT+0100 (BST) new Date('1972-10-31'); Date Tue Oct 31 1972 23:59:59 GMT+2359 (GMT) new Date('1972-06-12'); Date Mon Jun 12 1972 01:00:00 GMT+0100 (BST) new Date('1973-06-12'); Date Tue Jun 12 1973 00:59:58 GMT+0059 (BST) new Date('2077-06-12'); Date Sat Jun 12 2077 00:59:33 GMT+0059 (BST)
(In reply to tech-lists from comment #4) Make sure you're NOT using the WITH_ZONEINFO_LEAPSECONDS_SUPPORT option in src.conf when building the system.
(In reply to andrew from comment #5) Now, that might be it. That setting is present on the desktop in /etc/src.conf on both the desktop and the vm. I'll install a 12.1-R vm, install firefox as a pkg from pkg.freebsd.org and re-test thanks
OK, made a 12-stable vm from downloaded snapshot, installed firefox and it reports a sane new Date(): new Date() Date Wed Jul 29 2020 18:29:23 GMT+0100 (BST) new Date().getTimezoneOffset() -60 I've commented out the leapseconds line in /etc/src.conf on the desktop and it's now rebuilding, will try that and get back.
That option should probably have a warning on it: a) it violates the posix spec b) as a result of (a), it leads to strange and often unpredictable inconsistencies and/or failures; some software will fail to handle timezones at all if leapseconds are enabled.
(In reply to andrew from comment #5) Well done, that was it. I'd never have guessed, nor did lots of others. Now it's sane on the 12-stable desktop too: new Date() Date Wed Jul 29 2020 19:30:53 GMT+0100 (BST) new Date().getTimezoneOffset() -60 Thanks very much. One thing I was wondering though, is how come iridium was unaffected? different javascript implementation?
^Triage: request feedback from author of a relevant commit (base r320702)
(In reply to tech-lists from comment #9) Does iridium's output from new Date() with leapseconds enabled match the system time, or is it 27 seconds off?
(In reply to andrew from comment #11) Hi, It matches system time
(this is what led me to initially think it was a firefox problem in particular).
I propose something along the lines of: https://reviews.freebsd.org/D25902
closing as not a bug in the firefox port, but a consequence of enabling leapseconds in /etc/src.conf