Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Brooks Harris]

On 2020-02-06 7:28 AM, Seaman, Robert Lewis - (rseaman) wrote:


Hello all,

The fundamental answer / constraint to all questions of engineering, 
including temporal engineering, is funding. No bucks, no Buck Rogers. 
"Time" is a vast topic, pretty much as big as "space". Precision 
timekeeping topics are only somewhat smaller in practical terms since 
issues of anthropology and philosophy, etc., that may be far afield in 
other kinds of engineering, remain remarkably pertinent.


Funding falls into per-project and per-community responsibilities. 
Per-project, the engineering requirements related to timekeeping are 
remarkably diverse. You can read about the resulting timekeeping 
solution we implemented in support of our Near-Earth Asteroid (NEA) 
survey (https://arxiv.org/abs/1807.01370), but the precise mix of 
ingredients varies even between astronomical observatories. The short 
answer, per-project, is that organizations should plan and budget for 
timekeeping just as with any other critical infrastructure.



Rob,

I think that's a terrific and interesting article. Thanks.

-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Warner Losh]

On Thu, Feb 6, 2020 at 7:17 AM Brooks Harris  wrote:

> On 2020-02-06 9:08 AM, Warner Losh wrote:
>
>
>
> On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak  wrote:
>
>> Hi Hal,
>>
>> It's 2020. How on earth can NTP still not implement UTC correctly, in all
>> cases? Or is it a fundamental NTP design flaw?
>>
>
> Design flaw. NTP time stamps can't encode a leap second. It can therefore
> never really work in all cases. We are left with what hack do you want to
> do today.
>
> You can't fit 86401 pegs in 86400 holes. Something's got to go. No
> agreement on what goes.
>

Exactly. We have a number of different hacks that we use to keep the
problems under control, to discard potentially bad data, to filter bad data
that we can't discard, etc. It's a series of hacks that usually work well.
Not because it's well specified, but because different implementations have
programmed defensively to ensure that the current spec + unwritten policy
rules + some known past bugs are filtered so ntpd doesn't react when it's
likely a bad time. This will fail, of course, if we ever have a leap second
in March or September. It's working for the conditions we have today, which
is great, but it's not robust or resilient.

> The Z3801A issue doesn't sound like an NTP problem. This is a known legacy
>> Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or
>> even two GPS WNRO problems buy now?
>>
> Known past issues are likely future problems. 40 years in software has
> taught me that we do not always learn and apply the lessons of the past.
> Every 5-10 years we swap out the coders that learned them for newer,
> cheaper labor. Or there are new players in a niche that have more hubris
> than tribal knowledge. This guarantees bugs will repeat.
>
> Especially in the absence of clear specifications.
>

Yes. That's exactly what I meant by tribal knowledge. We could all tell
long stories about how we learned all the details because of that absence...

Warner


> Warner
>
>
> /tvb
>>
>> On 2/6/2020 1:41 AM, Hal Murray wrote:
>>
>> tvb said:
>>
>> There's no ambiguity. Those are just bugs. No software should depend on  more
>> than 1 month notice of a leap second and no software should be  fooled if the
>> notice is months or even years in advance.
>>
>> There are plenty of quirks in ntp code along that line.  The APIs don't have
>> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
>> have most of the next day to turn it off.  The leap-pending on the wire is
>> leap-at-the-end-of-this-month.
>>
>> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
>> June or December.  It's a hack, but it gets the job done and the code wasn't
>> setup to ask it when the leap would happen.
>>
>>
>> tvb said:
>>
>> If you're writing a FAQ or best practices guide stay in touch. I have a
>> semi-technical leap second report in the works. UTC is actually very  simple;
>> but it's been complicated by untold levels of bad assumptions,  bad
>> execution, and bad prose.
>>
>> Are you going to say anything about POSIX?
>>
>>
>>
>>
>> ___
>> LEAPSECS mailing list
>> LEAPSECS@leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>
>
> ___
> LEAPSECS mailing 
> listLEAPSECS@leapsecond.comhttps://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Brooks Harris]

On 2020-02-06 9:08 AM, Warner Losh wrote:



On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak > wrote:


Hi Hal,

It's 2020. How on earth can NTP still not implement UTC correctly,
in all cases? Or is it a fundamental NTP design flaw?


Design flaw. NTP time stamps can't encode a leap second. It can 
therefore never really work in all cases. We are left with what hack 
do you want to do today.
You can't fit 86401 pegs in 86400 holes. Something's got to go. No 
agreement on what goes.


The Z3801A issue doesn't sound like an NTP problem. This is a
known legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe
also affected by one or even two GPS WNRO problems buy now?

Known past issues are likely future problems. 40 years in software has 
taught me that we do not always learn and apply the lessons of the 
past. Every 5-10 years we swap out the coders that learned them for 
newer, cheaper labor. Or there are new players in a niche that have 
more hubris than tribal knowledge. This guarantees bugs will repeat.

Especially in the absence of clear specifications.
-Brooks


Warner


/tvb


On 2/6/2020 1:41 AM, Hal Murray wrote:

tvb said:

There's no ambiguity. Those are just bugs. No software should depend on  
more
than 1 month notice of a leap second and no software should be  fooled if 
the
notice is months or even years in advance.

There are plenty of quirks in ntp code along that line.  The APIs don't have
an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
have most of the next day to turn it off.  The leap-pending on the wire is
leap-at-the-end-of-this-month.

I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
June or December.  It's a hack, but it gets the job done and the code wasn't
setup to ask it when the leap would happen.


tvb said:

If you're writing a FAQ or best practices guide stay in touch. I have a
semi-technical leap second report in the works. UTC is actually very  
simple;
but it's been complicated by untold levels of bad assumptions,  bad
execution, and bad prose.

Are you going to say anything about POSIX?




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com 
https://pairlist6.pair.net/mailman/listinfo/leapsecs



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Warner Losh]

On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak  wrote:

> Hi Hal,
>
> It's 2020. How on earth can NTP still not implement UTC correctly, in all
> cases? Or is it a fundamental NTP design flaw?
>

Design flaw. NTP time stamps can't encode a leap second. It can therefore
never really work in all cases. We are left with what hack do you want to
do today.

> The Z3801A issue doesn't sound like an NTP problem. This is a known legacy
> Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or
> even two GPS WNRO problems buy now?
>
Known past issues are likely future problems. 40 years in software has
taught me that we do not always learn and apply the lessons of the past.
Every 5-10 years we swap out the coders that learned them for newer,
cheaper labor. Or there are new players in a niche that have more hubris
than tribal knowledge. This guarantees bugs will repeat.

Warner


/tvb
>
> On 2/6/2020 1:41 AM, Hal Murray wrote:
>
> tvb said:
>
> There's no ambiguity. Those are just bugs. No software should depend on  more
> than 1 month notice of a leap second and no software should be  fooled if the
> notice is months or even years in advance.
>
> There are plenty of quirks in ntp code along that line.  The APIs don't have
> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
> have most of the next day to turn it off.  The leap-pending on the wire is
> leap-at-the-end-of-this-month.
>
> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
> June or December.  It's a hack, but it gets the job done and the code wasn't
> setup to ask it when the leap would happen.
>
>
> tvb said:
>
> If you're writing a FAQ or best practices guide stay in touch. I have a
> semi-technical leap second report in the works. UTC is actually very  simple;
> but it's been complicated by untold levels of bad assumptions,  bad
> execution, and bad prose.
>
> Are you going to say anything about POSIX?
>
>
>
>
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Martin Burnicki]

Seaman, Robert Lewis - (rseaman) wrote:
[...]
> We are extremely happy with the quality and support we have received
> from Meinberg, ...
Thanks, Rob, I'm very happy to hear this.

[...]
> (I have no financial interests in Meinberg or NTF.)

Disclaimer: ;-)

Even though I'm working for Meinberg, I'd like to point out that what I
usually write in this and similar mailing lists is also not due to
financial interests of any kind.

It's just my personal opinion, from my technical and practical point of
view.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Martin Burnicki]

Hal Murray wrote:
> 
> tvb said:
>> There's no ambiguity. Those are just bugs. No software should depend on  more
>> than 1 month notice of a leap second and no software should be  fooled if the
>> notice is months or even years in advance. 

Please keep in mind that e.g. GPS sends out leap second announcements
about 6 months in advance. This is not a problem if the receiver
firmware follows the specs, since the week number and day number are
specified. But, as we have seen, this can be a problem due to bugs in
the receiver firmware.

> There are plenty of quirks in ntp code along that line.  The APIs don't have 
> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You 
> have most of the next day to turn it off.  The leap-pending on the wire is 
> leap-at-the-end-of-this-month.

I think this is some "best practice" that has evolved over many years.
For the kernel, the "end of this day" announcement is sufficient.

For the protocol, roughly 1 month is sufficient but short enough to
avoid ambiguous dates, i.e. at the end of which month.

If I remember correctly, the PTP specs even specify an announcement
interval of 12 hours only, the German DCF77 transmitter sends the
announcement only 1 hour in advance, and IRIG time codes (if they
support it at all, like IEEE1344 / C37.118) only 10 seconds or so in
advance.

So I wonder which spec should have been relevant for NTP/ntpd?

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Martin Burnicki]

Tom Van Baak wrote:
> Hi Hal,
> 
> It's 2020. How on earth can NTP still not implement UTC correctly, in
> all cases? Or is it a fundamental NTP design flaw?

A program like ntpd (or ptpd, FWIW) has to rely on available sources of
information, and if those sources provide wrong information, this can
produce wrong results.

Of course there can be (and have been) bugs in the way ntpd handled leap
seconds. However, I'm not aware of any bufg in the current ntpd code.

Originally ntpd accepted a leap second from any upstream source that
announced it, and forwarded the announcement to its clients.

However, after it had happened that some GPS receiver models had sent a
faulty leap second announcement which the server forwarded to its
clients, the code in ntpd was modified in a way that a client accepts a
leap second announcement only if a majority of its upstream servers
provides the announcement.

If you implement a plausibility check that accepts leap second only at
the end of June or December, you avoid (at the first glance) that your
server's time is messed up if a faulty device sends an announcement at
the end of the wrong month.

But what if your GPS receiver sends a wrong leap second announcement at
the end of December, when there is no real leap second, or does *not*
send an announcement if a leap second has been scheduled?

If the GPS receiver which sends a wrong leap second announcement also
applies the leap second to its internal time, then the time sent by the
receiver is off by 1 s after the false leap second event.

What should a program do that has the GPS receiver as its sole time
source? Stop synchronizing to the receiver, or follow the time step
after some time if the 1 s offset persists?

What if the GPS satellites start sending data that cause the UTC
correction by GPS receivers to be 13 microseconds off? Is NTP to blame
if it follows the GPS receiver's time?

Which is the offset range that should be accepted if an "authoritative"
time source like a GPS receiver starts sending a different time?

So I wonder why NTP (the protocol) or ntpd (the implementation) are
blamed here. There's a lot of stuff in there which tries to sort out
errors coming from external time sources, but I doubt there can be an
implementation which is in no way affected by any potential error from
outside.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Seaman, Robert Lewis - (rseaman)]

Hello all,

The fundamental answer / constraint to all questions of engineering, including 
temporal engineering, is funding. No bucks, no Buck Rogers. “Time” is a vast 
topic, pretty much as big as “space”. Precision timekeeping topics are only 
somewhat smaller in practical terms since issues of anthropology and 
philosophy, etc., that may be far afield in other kinds of engineering, remain 
remarkably pertinent.

Funding falls into per-project and per-community responsibilities. Per-project, 
the engineering requirements related to timekeeping are remarkably diverse. You 
can read about the resulting timekeeping solution we implemented in support of 
our Near-Earth Asteroid (NEA) survey (https://arxiv.org/abs/1807.01370), but 
the precise mix of ingredients varies even between astronomical observatories. 
The short answer, per-project, is that organizations should plan and budget for 
timekeeping just as with any other critical infrastructure.

For example, we operate facilities in 6 buildings in 3 diverse locations, 
including two remote mountaintops. So we bought 3 commercial GNSS clocks and 
ran fiber between the pairs of buildings. We are extremely happy with the 
quality and support we have received from Meinberg, and I am happy to leave the 
NTP server-side updates to them, rolled into their occasional firmware updates. 
These updates have included significant feature improvements, including a nifty 
time synchronization monitor tool. My boss might call it the world’s most 
boring video game, but really that’s kind of the point. Many of the figures in 
the preprint above came directly from our Meinberg clocks. The cost of these 
clocks and related equipment is in the ballpark (baseball for “similar to”) for 
other classes of computing infrastructure. We don’t expect commodity computers 
to do hardware time-capture out of the box.

At the moment we are commissioning operations on another telescope on yet 
another mountaintop and will probably buy another GNSS clock to provide both 
hardware time capture and NTP services. We are also planning a project-wide OS 
upgrade for which chronyd is the default NTP option and are evaluating its 
performance, which is to say that project timekeeping operations costs continue.

Per-community, NTP is just one tool in a larger toolkit, but even so the 
panoply of NTP engineering requirements across many hundreds or thousands of 
projects is more diverse than POSIX or IETF have ever even attempted to 
capture, and funding has to compete with many other host-level and 
network-level standards. The Network Time Foundation (https://www.nwtime.org) 
supports the core NTP project, but NTF’s responsibilities are themselves 
broader than NTP. How many organizations support (financially) all the 
organizations like NTF that are responsible for standards, APIs, and protocols 
they rely on? Heck, how many of us read and respond to this 
professionally-relevant mailing list off-the-clock (as it were), as I am doing 
right now, rather than during work hours?

Many people reading this are their organization’s expert on timekeeping issues, 
and time is likely of significant importance to your organization if you are 
still reading to the end of this message. Ask yourself if your project, 
company, or community budgets for timekeeping infrastructure, operations, and 
standards proportional to their impact and risks, positive and negative, to 
your mission? I believe one reason Meinberg added its very useful syncmon tool 
was to address customers’ precise-timekeeping reporting requirements, 
especially for financial institutions, who attach equally precise estimates of 
its value in units of currency.

What’s time worth to you?

Rob Seaman
Catalina Sky Survey
Lunar and Planetary Laboratory

(I have no financial interests in Meinberg or NTF.)
--

Hi Hal,

It's 2020. How on earth can NTP still not implement UTC correctly, in all 
cases? Or is it a fundamental NTP design flaw?

The Z3801A issue doesn't sound like an NTP problem. This is a known legacy 
Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or even 
two GPS WNRO problems buy now?

/tvb

On 2/6/2020 1:41 AM, Hal Murray wrote:

tvb said:

There's no ambiguity. Those are just bugs. No software should depend on  more

than 1 month notice of a leap second and no software should be  fooled if the

notice is months or even years in advance.

There are plenty of quirks in ntp code along that line.  The APIs don't have

an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You

have most of the next day to turn it off.  The leap-pending on the wire is

leap-at-the-end-of-this-month.



I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was

June or December.  It's a hack, but it gets the job done and the code wasn't

setup to ask it when the leap would happen.





tvb said:

If you're writing a FAQ or best practices guide stay in touch. I have a

semi-technical leap seco

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Brooks Harris]

On 2020-02-06 5:22 AM, Tom Van Baak wrote:


Hi Hal,

It's 2020. How on earth can NTP still not implement UTC correctly, in 
all cases? Or is it a fundamental NTP design flaw?


The Z3801A issue doesn't sound like an NTP problem. This is a known 
legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected 
by one or even two GPS WNRO problems buy now?


If I understand this correctly Google Smear (and others, AWS, Bloomberg, 
etc) is a work-around to prevent possible system failure on 
leap-seconds. This is their primary concern, not leap-second accuracy. 
There are many potential ways a system or application might fail on 
leap-second depending on the implementations. At least one failure that 
was documented was what I'd call a 'stupid' bug where the code driving 
the output to the logging mechanism hung the kernel, setting off race 
conditions that took the whole data center down. It wasn't a bug in the 
handing of the leap-second itself but a bug in the reporting of the 
leap-second. Any given version of any OS might have some sort of bug in 
their leap-second handling or some related service.


Those data centers have millions of OS instances running on many 
different cpus (Intel, AMD, etc) on many different platforms (blades, 
etc), probably including various versions of Linux and Unix, Windows, 
Macintosh, and possibly main frame OSs. It is infeasible to upgrade all 
these at once only for leap-second or NTP updates because any OS version 
may have side effects that potentially upset the many critical 
applications running of each OS and it's subsystems. Potential side 
effects of the application behavior is a bigger risk than any 
leap-second behavior. The updates and upgrades must proceed very 
carefully in stages. Who knows how old some of these tiers might be. 
We've also heard complaints that many systems have not upgraded their 
NTP, with old systems still deployed. Its a very complex maintenance issue.


The potential practical problems related to leap-seconds implementation 
far outweigh the concern of accurate timekeeping. It will be many years 
before A) all OSs have identical and correct leap-second support 
(especially since the specs and common practices are vague and Windows 
is intentionally diverging from POSIX compliance), and B) the time-link 
systems, NTP, PTP, etc, also have identical behavior consistent with the 
OS's treatment.


It looks to me the smears will be with us for a very long time much to 
the frustration to those who wish computer timekeeping could be 
accurate. I don't see how consistency comes about without significant 
investment and this seems unlikely as the timing community debates the 
fate of the leap-second and no efforts are made to clarify the specs. 
The leap-second is evil but it looks like its with us for a very long 
time to come.


-Brooks


/tvb


On 2/6/2020 1:41 AM, Hal Murray wrote:

tvb said:

There's no ambiguity. Those are just bugs. No software should depend on  more
than 1 month notice of a leap second and no software should be  fooled if the
notice is months or even years in advance.

There are plenty of quirks in ntp code along that line.  The APIs don't have
an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
have most of the next day to turn it off.  The leap-pending on the wire is
leap-at-the-end-of-this-month.

I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
June or December.  It's a hack, but it gets the job done and the code wasn't
setup to ask it when the leap would happen.


tvb said:

If you're writing a FAQ or best practices guide stay in touch. I have a
semi-technical leap second report in the works. UTC is actually very  simple;
but it's been complicated by untold levels of bad assumptions,  bad
execution, and bad prose.

Are you going to say anything about POSIX?






___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Tom Van Baak]

  
  
Hi Hal,
It's 2020. How on earth can NTP still not implement UTC
  correctly, in all cases? Or is it a fundamental NTP design flaw?

The Z3801A issue doesn't sound like an NTP problem. This is a
  known legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe
  also affected by one or even two GPS WNRO problems buy now?

/tvb

On 2/6/2020 1:41 AM, Hal Murray wrote:


  
tvb said:

  
There's no ambiguity. Those are just bugs. No software should depend on  more
than 1 month notice of a leap second and no software should be  fooled if the
notice is months or even years in advance. 

  
  
There are plenty of quirks in ntp code along that line.  The APIs don't have 
an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You 
have most of the next day to turn it off.  The leap-pending on the wire is 
leap-at-the-end-of-this-month.

I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was 
June or December.  It's a hack, but it gets the job done and the code wasn't 
setup to ask it when the leap would happen.


tvb said:

  
If you're writing a FAQ or best practices guide stay in touch. I have a
semi-technical leap second report in the works. UTC is actually very  simple;
but it's been complicated by untold levels of bad assumptions,  bad
execution, and bad prose. 

  
  
Are you going to say anything about POSIX?





  

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Hal Murray]

tvb said:
> There's no ambiguity. Those are just bugs. No software should depend on  more
> than 1 month notice of a leap second and no software should be  fooled if the
> notice is months or even years in advance. 

There are plenty of quirks in ntp code along that line.  The APIs don't have 
an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You 
have most of the next day to turn it off.  The leap-pending on the wire is 
leap-at-the-end-of-this-month.

I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was 
June or December.  It's a hack, but it gets the job done and the code wasn't 
setup to ask it when the leap would happen.


tvb said:
> If you're writing a FAQ or best practices guide stay in touch. I have a
> semi-technical leap second report in the works. UTC is actually very  simple;
> but it's been complicated by untold levels of bad assumptions,  bad
> execution, and bad prose. 

Are you going to say anything about POSIX?


-- 
These are my opinions.  I hate spam.



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Miroslav Lichvar]

On Wed, Feb 05, 2020 at 03:32:54PM -0800, Tom Van Baak wrote:
> Code should allow for a leap second event at the end of any month. The June
> / December thing is one of several guidelines for BIPM; it's not a rule that
> anyone writing UTC code should assume or depend on. Nor should code ever
> assume leap seconds are positive.

If the source can be trusted, yes, that would make sense. But in
reality, when working with not completely reliable information (due to
bugs in specifications, software, firmware, attacks, etc.), I think it
might be better to have the current June/December practice hardcoded.

For example, when a bug in an NTP implementation allowing leap seconds
to be inserted at any month caused them to sometimes get stuck and
repeat every month, the bogus leap seconds were spreading among
servers that didn't check what month it is.

How much energy is needed to slow down or speed up Earth enough for
UTC to require more than two leap seconds per year and how quickly can
it be released without destroying those that care about UTC following
UT1?

-- 
Miroslav Lichvar

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs