For rationale see:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248338
That people are turning on the option and then tripping over weird consequences suggests that some sort of warning is required.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
where is this at now that five years has passed? i see firefox no longer exhibits the strange behavior detailed in PR #248338 (well, not in America/Detroit, at least). However, WITH_ZONEINFO_LEAPSECONDS_SUPPORT still defaults to off and at least math/R refuses to build if it's on. (see also PR #271170)
seems like a straightforward doc change. any good reason this differential has stalled? i for one miss the man i was before i ever fiddled with that knob.
are we hoping support "should" improve in the application software ecosystem? do we anticipate broad compatibility and general portability to yet emerge? has it already? or at least been improving? should we treat breakage caused by enabling leap second support to be worthy the effort and coordination to resolve? (my hunch is "no" to all of these)
other than an authoritative root NTP server hardwired to an atomic clock (if even) what is the imagined use case for enabling this toggle? scientific use...realtime life and death applications...where the operation of the NTP client can lead to unreliable measurements, undefined behavior or catastrophe?
if i understand correctly, during the entire day preceding a leap second, we (as in society) "smear" time (so a clock second equals ~1.00001 "real" seconds) rather than count every second precisely and accurately. we (now as in sysadmins) leave all of this up to our timeservers while our other various servers and hosts will simply adjust for "drift", unaware of the special designation given to the day by the ITU. this keeps all days equal to 86400 seconds and all UTC epochtime midnights ending with 00. our kernel well supports tweaking clock "slew rate" in order to maintain monotonicity and avoid adjusting the clock directly [which would introduce abrupt steps].
the nonstandard optional support not only makes our libc aware that some (and which) days have 86401 seconds but then also reflects in our system epochtime the accurate count of uniform seconds since the epoch. this discrepancy between midnights and the non-uniformity of days causes issues with many applications, as POSIX decided all days shall have 86400 seconds and a "second" is whatever IERS (measures stellar bodies) rather than BIPM (measures subatomic particles) says it is.
Comment Actions
I don't know anyone who uses this option. I certainly don't test it. :-)
I don't mind additional documentation.
Comment Actions
Leap seconds are scheduled for deprecation by 2035.
There's something of a race on as to whether the deprecation will happen before the first instance of a negative leap second, which is something that approximately no software is ready for. (Every leap second since their invention has been positive, but there have been recent speedups in the Earth's rotation starting around 2020.)
The fact that these things are inherently unpredictable is the reason why POSIX pretends they don't exist. (From 1972-1998 they were an almost annual event; after 1998 there were none until 2005, and since then there have been only four: Dec 2008, Jun 2012, Jun 2015, Dec 2016.)
if i understand correctly, during the entire day preceding a leap second, we (as in society) "smear" time
No, we don't; I believe Google does it that way, but in civil timekeeping it is done by adding an entire second before midnight, so the clock goes 23:59:58, :59, :60, 00:00:00, :01 etc.
Comment Actions
Leap seconds are scheduled for deprecation by 2035.
that's a relief. i think it would be useful to add this fact to the proposed message. looks like it was decided in 2022, after the creation of this DR.
if i understand correctly, during the entire day preceding a leap second, we (as in society) "smear" time
No, we don't; I believe Google does it that way, but in civil timekeeping it is done by adding an entire second before midnight, so the clock goes 23:59:58, :59, :60, 00:00:00, :01 etc.
you're right; that's how civilization has defined it. i should've qualified "society" as strictly that of computer end users; the status quo we've collectively (or complacently) deemed "good enough" in practice. i blame the underspecified NTP protocol for our dogwater status quo.
without the option in question, freebsd never sees a 23:59:60. with the option, there are 27 days so far in history which zoneinfo/libc apportions 86401 seconds and, as you mentioned, none [yet] with 86399. either way, NTP lacks adequate specificity to unambiguously present 23:59:60 to the client (without necessary post-facto analysis of multiple responses). they went so far to well address the issue but stopped just short of that.
doing further research, it appears our "classic" ntpd (base or port) does not offer any such clever "smearing" as i described earlier. it (under either of the build configs in question) just holds onto 23:59:59 for a total of 2,000 ms, explicitly consulting and processing a leap-seconds.list file regardless of OS support. its worth noting that while the NTP server enforces the monotonicity of time regarding outgoing messages, the system time local to the server will indeed regress and repeat 1000 ms, reaching [UTC] midnight twice and crossing it once, in the default (WITHOUT) case.
since the default maximum clock discrepancy for choosing the [smooth] slew code path is just 128 ms, i think that means our client chooses the [abrupt] step (backward!), potentially exposing clock non-monotonicity to applications! this is not ideal. i suppose if that'd affect your use case then "classic" ntpd does not make for a very good stratum 1 server, with or without the topical src.conf option. (relaying still works well though.) the workaround there is to configure every client [of concern] with a "tinker step" > 1128 ms. the result would be the client [kernel] smears for ~30 minutes afterward rather than the server [daemon] smearing the whole day before.
net/chrony (just one i know of) provides for this 0.001% time "smearing" throughout the prior day if one truly wishes to serve a master chronometer to the network rather than rely on $AUTHORITY.
Comment Actions
This change is good. The problems with leapseconds are legend... but not at all relevant here.