Supposedly leap seconds are going to be formally abandoned in a little
more than a decade; but that conveniently ignores the vagaries of the
earth's wobbling, which are not deterministic, so it's just a different
kind of folly by our fellow meat puppets.
On 12/22/2022 23:13 PM, James Browning
> On 12/22/2022 7:49 PM PST Hal Murray via devel wrote:
>
>
> Fred Wright said:
> > If you make it 24 hours, there's the question of whether that means 86400
> > seconds or 86401. :-)
>
> That ones easy. It's 86400 smeared seconds and 86401 real seconds.
>
> That's the whole point of smearing.
Fred Wright said:
> If you make it 24 hours, there's the question of whether that means 86400
> seconds or 86401. :-)
That ones easy. It's 86400 smeared seconds and 86401 real seconds.
That's the whole point of smearing. :)
--
These are my opinions. I hate spam.
_
Fred Wright said:
> Any sane implementation of NTP ought to perform all synchronization on the
> TAI timescale, with conversions between TAI and UTC being part of the I/O.
> Using leap-smeared time on the wire makes this mapping inconsistent.
I agree, but most of the world is stuck with POSIX p
Yo Fred!
On Thu, 22 Dec 2022 17:00:37 -0800 (PST)
Fred Wright via devel wrote:
> On Wed, 21 Dec 2022, Hal Murray via devel wrote:
>
> > Google says:
> > https://developers.google.com/time/smear
> > We encourage anyone smearing leap seconds to use a 24-hour linear
> > smear from noon to noon U
On Wed, 21 Dec 2022, Hal Murray via devel wrote:
Google says:
https://developers.google.com/time/smear
We encourage anyone smearing leap seconds to use a 24-hour linear smear from
noon to noon UTC.
There were earlier versions which did sine rather than linear.
Hmm. I don't recall any non
Richard Laager said:
> I was asked to enable it in Debian, but I did not.
> Note that my understanding was that "enable" meant "compile in the support
> such that users could choose to enable it in the config" not "enable it by
> default".
That would be my expectation. I haven't explored the
On 12/21/22 17:26, Hal Murray via devel wrote:
Does anybody use it?
Do any distros build with it enabled?
Should we add an "#warn untested" to the code?
I was asked to enable it in Debian, but I did not.
Note that my understanding was that "enable" meant "compile in the
support such that use
Yo Fred!
On Wed, 21 Dec 2022 18:21:39 -0800 (PST)
Fred Wright via devel wrote:
> On Wed, 21 Dec 2022, Hal Murray via devel wrote:
>
> > Does anybody use it?
> > Do any distros build with it enabled?
> > Should we add an "#warn untested" to the code?
>
> If some systems need leap-smeared time
On Wed, 21 Dec 2022, Hal Murray via devel wrote:
Does anybody use it?
Do any distros build with it enabled?
Should we add an "#warn untested" to the code?
If some systems need leap-smeared time to get around bugs in their code,
they should be free to implement an *internal* leap-smeared tim
Does anybody use it?
Do any distros build with it enabled?
Should we add an "#warn untested" to the code?
static void
leap_smear_add_offs(l_fp *t) {
t += leap_smear.offset;
}
clang 13 points out:
../../ntpd/ntp_proto.c:2210:27: warning: parameter 't' set but not used
[-Wunused-but-set
11 matches
Mail list logo
