Bug 248338 - www/firefox: JavaScript Does not return whole number in for getTimezoneOffset (when src.conf WITH_ZONEINFO_LEAPSECONDS_SUPPORT=yes)
Summary: www/firefox: JavaScript Does not return whole number in for getTimezoneOffset...
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-gecko (Nobody)
Keywords: needs-qa
Depends on:
Reported: 2020-07-29 01:29 UTC by tech-lists
Modified: 2020-09-22 13:47 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (gecko)
koobs: maintainer-feedback? (ngie)


Note You need to log in before you can comment on or make changes to this bug.
Description tech-lists 2020-07-29 01:29:47 UTC

"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
Comment 1 andrew 2020-07-29 01:53:25 UTC
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?
Comment 2 tech-lists 2020-07-29 05:11:38 UTC
(In reply to andrew from comment #1)

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.
Comment 3 tech-lists 2020-07-29 05:36:20 UTC
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?
Comment 4 tech-lists 2020-07-29 05:53:34 UTC
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)
Comment 5 andrew 2020-07-29 06:15:29 UTC
(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.
Comment 6 tech-lists 2020-07-29 14:16:29 UTC
(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

Comment 7 tech-lists 2020-07-29 17:38:08 UTC
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()

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.
Comment 8 andrew 2020-07-29 18:30:02 UTC
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.
Comment 9 tech-lists 2020-07-29 18:35:26 UTC
(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()

Thanks very much.

One thing I was wondering though, is how come iridium was unaffected? different javascript implementation?
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-30 07:51:08 UTC
^Triage: request feedback from author of a relevant commit (base r320702)
Comment 11 andrew 2020-07-30 09:37:27 UTC
(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?
Comment 12 tech-lists 2020-07-30 12:29:12 UTC
(In reply to andrew from comment #11)

It matches system time
Comment 13 tech-lists 2020-07-30 13:07:28 UTC
(this is what led me to initially think it was a firefox problem in particular).
Comment 14 andrew 2020-07-31 02:45:35 UTC
I propose something along the lines of:

Comment 15 tech-lists 2020-09-22 13:47:19 UTC
closing as not a bug in the firefox port, but a consequence of enabling leapseconds in /etc/src.conf