Subject: [Ntp] Timescales, leapseconds and smearing

From: Kurt Roeckx <[email-masked]>
Date: Mon, 7 Dec 2020 23:27:35 +0100

We have various timescales people might care about:
- NTP
- TAI
- Smeared NTP
- UT1
- UTC
- UNIX time
- TT
- GPS
- Others

There are relations between those time scales, some are fixed,
others not.

The proposed draft has support for the first 4, and offsets
between some of them. Note that it calls the NTP timescale
UTC, which it's not.

One problem that NTP currently isn't very good at is dealing with
the leap second. The current draft proposal doesn't address the
problems. The major problems with it are:
- The NTP timescale is non-continues in case of a leap second,
  without an indication of on which scale you are. It also
  doesn't define which second should get repeated. This means there
  is a 2 second window where it's unclear what the time is.
- There is a need to distribute information about when a leap second
  will happen, which for can happen over NTP or some other way.
  Experience shows that a lot of NTP servers get this wrong,
  resulting in synchronization problems when some servers change
  and others not. When distributed over NTP, a majority of the
  servers need to indicate that it will happen. There is no way
  to indicate that you don't know a leap second will happen or
  not, making it harder to get it correct.

You can fix the first problem by moving to a scale that is
continues, like TAI. But I'm not sure if it's better or worse
because of the 2nd problem, it will probably be about the same.
In TAI it would always be clear what the time means, even if some
servers know about the leap seconds and others not. It would avoid
marking some servers as false tickers. The current proposed draft
supports working in TAI and smeared NTP. I'm not sure about the
UT1 scale in the draft but assume it's non-continues.

An other way to fix the non-continues problem is to have some
indication of on which scale you are. It needs to be able to say
in which scale each of the timestamps is. The proposed draft has a
TAI-UTC offset if you use the NTP scale that could be used for this,
but it would then apply to both timestamps. If that is what we
want to do, it needs to be more clear. But for the UT1 scale there
is no way to indicate it.

NTP could distribute information about difference between
timescales. A leap second will change the offsets, so we already
do this in a very limited way. TAI-UTC and UT1-UTC are mentioned in
the proposed draft, but it depends on which timescale you're using
which offset you can get. I'm not sure NTP is the best way to
distribute it. But for a lot of devices NTP is the only source of a
leap second information.

The document also has a smeared NTP option. It doesn't actually
say which time you put in the fields, the NTP time, or the smeared
NTP time. It then has an offset to the NTP time, without being
clear about the sign. The offset is also optional, which means you
might not be able to combine servers that smear, that smear
differently and that don't smear.

I'm currently not sure if we should do something with smearing. We
could for instance say that even if the server is smearing, NTP
should always contain unsmeared time, and that smearing is an
implementation detail. Or we could standardize how it should be
smeared. Or like the current draft that you have smear offset.

Kurt

---

From: Steve Allen <[email-masked]>
Date: Mon, 7 Dec 2020 15:02:28 -0800

On Mon 2020-12-07T23:27:35+0100 Kurt Roeckx hath writ:
> I'm not sure about the

UT1 as it is made available is piecewise continuous.
UT1 is given in the form of tables of (UT1 - UTC) for various dates.
An implementation would have to determine whether to use linear
interpolation or something with higher order.

For dates from the present to the not to distant future UT1 is
presented as tables of values of predicted differences UT1-UTC for
various dates in IERS Bulletin A

https://www.iers.org/SharedDocs/News/EN/BulletinA.html

These predicted values would have to be used for operational systems
trying to provide UT1 in real time.

For dates in the recent past UT1 is presented as tables of values of
measured differences UT1-UTC for various dates in IERS Bulletin B

https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html

For dates back to the origin of atomic time scales in 1962 UT1 is best
available in series C04

https://www.iers.org/IERS/EN/DataProducts/EarthOrientationData/eop.html

Before 1962 there was no worldwide source of atomic time, so before
1962 every event that was recorded uses Universal Time.

Seen from the perspective of TAI providing UT1 is a form of smearing.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 00:13:35 +0100

> is no way to indicate it.

One thing I forgot to mention is that if there can be doubt about
what the timestamp field means, the packet could just be dropped,
so from 1 second before the leap second, to 1 second after the
leap second, for a total of 3 seconds.

> distribute it. But for a lot of devices NTP is the only source of a

I guess that should say current leap second information. There is
of course a class of devices that should use SNTP and so don't
really care about the leap second. But there probably are also
devices that do care about it, have the option to get it, but
don't get it.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 00:23:06 +0100

> interpolation or something with higher order.

I was talking about the time around the leap second. Where the
encoding in the NTP protocol might removed the leap seconds, or
includes the leap seconds.

Kurt

---

From: Steve Allen <[email-masked]>
Date: Mon, 7 Dec 2020 15:25:54 -0800

> https://www.iers.org/IERS/EN/DataProducts/EarthOrientationData/eop.html

I should also point out that any operational NTP scheme MUST NOT
obtain the information from IERS directly because they do not have the
funding to operate a service robust enough to be used by the entire world.

The relevant parts of the IERS publications would have to be availble
through some form of authoritative syndication.

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 15:48:58 -0800

> We have various timescales people might care about:

Current on-the-wire NTP format is only 32 bits of seconds since start of 
epoch.  Should we extend that to 64 bits so we never have to worry about 
epochs?

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 8 Dec 2020 10:31:04 +0100

> between some of them. Note that it calls the NTP timescale

How do you suggest it should be called?

>   not, making it harder to get it correct.

That's a good point. It would help have a special value, or a flag,
for the unknown case.

> is no way to indicate it.

The draft says the offset is for the receive timestamp. The client can
calculate it for the transmit timestamp in the non-ambiguous
timescales.

If the client cares about the ambiguity, it should use a non-ambiguous
timescale. Of course, both server and client need to support that.
Clients using ambiguous timescales can be recommended to ignore any
measurements around the leap second, as some current implementations
do.

> smeared. Or like the current draft that you have smear offset.

We should consider the reasons why server leap smearing is currently
used. I think the main one is that most NTP clients cannot be
configured to correct the clock for a leap second by a controlled
slew. If they could do that, there would be no need to do it on the
server.

If NTPv5 had a special leap-smeared timescale, would be the clients
actually updated to request it? I doubt it.

Maybe it would be better to just have a single flag for the server to
announce it is implementing a leap-smear. Clients could at least
detect mixing of smearing and non-smearing servers and better handle
the case when it knows about the leap second from a separate source.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 8 Dec 2020 10:33:53 +0100

> epoch.  Should we extend that to 64 bits so we never have to worry about 

Making the NTP timestamps 96-bit?

The NTPv5 draft has an 8-bit extension of the receive timestamp, which
covers ~35000 years.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 08 Dec 2020 10:56:24 +0100

Hi!

I think if we agree to use anything other than UTC in NTPv5, we absolutely
need to specify some use-level API how to get the current time:
time()
gettimeofday()
clock_gettime()
localtime()
strftime()

They all assume UTC... It's rather useless if NTP has the exact time, but no
("standard") program can use it.

Regards,
Ulrich

>>> Kurt Roeckx <[email-masked]> schrieb am 07.12.2020 um 23:27 in Nachricht
<[email-masked]>:
> ‑ NTP
> ‑ TAI
> ‑ Smeared NTP
> ‑ UT1
> ‑ UTC
> ‑ UNIX time
> ‑ TT
> ‑ GPS
> ‑ Others
> ‑ The NTP timescale is non‑continues in case of a leap second,
> ‑ There is a need to distribute information about when a leap second
> UT1 scale in the draft but assume it's non‑continues.
> 
> An other way to fix the non‑continues problem is to have some
> TAI‑UTC offset if you use the NTP scale that could be used for this,
> do this in a very limited way. TAI‑UTC and UT1‑UTC are mentioned in
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 12:05:42 +0100

> ("standard") program can use it.

They don't use UTC, they use POSIX/UNIX time. POSIX time, just like
NTP, ignores the leap seconds. POSIX actually says that the length
of a second is not specified, an implementation can then say it's
SI seconds. POSIX has support for a leap second in struct tm, so as
long as you don't convert it to a time_t you can work in UTC.
strftime() works with a struct tm, so can work in UTC.

The linux kernel has support for TAI. You can set a TAI offset, so
that applications making use of the POSIX API still get the POSIX
time. The clock_gettime() function you mentioned has TAI support.
The information to convert from TAI to UTC is available, so it's
possible to work in TAI or UTC on Linux, it's just that most
applications don't.

Kurt

---

From: Steve Allen <[email-masked]>
Date: Tue, 8 Dec 2020 08:18:56 -0800

> includes the leap seconds.

If correctly implemented the continuity of a UT1-like scale around a
leap second should not differ from the continuity of that UT1-like
scale at any other time.  Whatever filtering and interpolation is
being done to produce the UT1-like scale should be aware of the
leap second and aware that UT1 itself is unaffected by that.

---

From: Steve Allen <[email-masked]>
Date: Tue, 8 Dec 2020 08:44:29 -0800

> How do you suggest it should be called?

More generally, I think that names of the time scales in the document
all need an introductory explanation of what they mean.

Look at monthly issues of BIPM Circular T and it becomes evident that
there is no "UTC" which is available in real time.  Sources of time
which can be used by an NTP server there are only
UTC(pick a laboratory)

Note in the issues of Circular T that the Bulgarian Institute of
Metrology (BIM) has had UTC-UTC(BIM) values around 12 microseconds
during the entire year 2020.  Nevertheless, UTC(BIM) is the legal
time in Bulgaria, and devices in Bulgaria might be constrained by
regulations that require they use UTC(BIM) rather than another
UTC which is in better agreement with the rest of the world.

The draft does not mention the source or authority for the values of
UTC, UT1, TAI which are provided by NTP.  The draft almost certainly
cannot specify particular sources of time values, and in the case of
TAI there can be no source because TAI is not defined until next
month when Circular T is published for this month.

The draft should include definitions for UTC, TAI, UT1 as used by NTP.
At least for the case of TAI (but maybe for the other time scales
also) the draft should include explicit text indicating that in the
context of NTP those terms are used in a generic sense that does not
specify how the values of time from NTP are related to the actual
authoritative sources of those time scales.

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 8 Dec 2020 18:29:25 +0100

Kurt Roeckx wrote:
[...]
> the leap second.

Hm, I think the problems aren't due to the protocol but due to the
environments where NTP implementations are expected to run.

If you consider NTP just like a kind of transportation, it has to rely
on the information coming in from different sources, e.g.

- leap second schedule and TAI offset from a leapsecond file

- leap second schedule and TAI offset from a GPS receiver, if the
protocol (e.g. NMEA) supports this at all

- Leap second warning but no TAI offset, e.g. from DCF77

- leap second warning only very shortly before it happpens, e.g 1 hour
for DCF77, or 10 seconds (IIRC from IRIG, only with IEEE extensions)

There are e.g. GPS receivers out there which provided faulty leap second
warnings, e.g. at the end of September. What should a stratum 1 server
do when it receives such a warning from its trusted reference clock?

At the other side of the transport are the operating systems. Most Unix
systems just step the time back by 1 second to insert a leap second.
Other operating systems (e.g. Windows, except very current versions)
didn't know about leap seconds at all.

If a stratum 1 server receives a valid leap second warning early enough,
it can pass this down to its clients, but it doesn't know what the
clients do with it.

If a PTP slave receives a leap second warning from its grandmaster and
passes it down to its Unix kernel which runs on UTC, the same problems
will occur if the system time is stepped back by the kernel.

> The current draft proposal doesn't address the
>   doesn't define which second should get repeated.

As said above, it's not a decision of an NTP daemon how a leap second is
to be handled. If the kernel just steps the time back and whether it
repeats the last or the first second is up to the kernel, as long as the
kernels don't provide any other API.

>   This means there

ntpd from ntp.org sends "not synchronized" for a short interval across a
leap second. This has been proposed by Miroslav some time ago, and is
IMO a very good way to come across the leap second.

>   will happen, which for can happen over NTP or some other way.

This was a feature of the Autokey protocol and extensions, even though I
have to admit that it's not really related to Autokey. Not sure if there
is a replacement in the new extension fields.

>   not, making it harder to get it correct.

See my comments above. What should an NTP server do if a trusted source
provides invalid information?

IMO you can't blame NTP servers for this. The majority vote of a client
is a good thing to discard such faulty announcements.

> marking some servers as false tickers.

I'm not sure it is so easy. If you switch to TAI you always need a
reliable source for the TAI offset, and the TAI offset has to be
forwarded down the time synchronization chain.

If your trusted source for the TAI offset provides faulty information
(as with the leap second warning above), you will run into the same
problems down the synchronization chain.

> The current proposed draft

If you talk about smeared leap seconds, the questions are still

- what shape is used? cosine, linear, ...

- what interval? 2 hours? 24 hours?

- is smearing half before / half after the leap second,
  or fully before the leap second?

> is no way to indicate it.

One possible way that come to my mind is to use an arbitrary time (which
ever), and provide an UTC or TAI offset (including fractions of a
second) in an extension field.

That would be similar to the times used in emails, where the main
timestamp is some local time, but an offset allows to determine the
associated UTC time.

> distribute it. But for a lot of devices NTP is the only source of a

There is also tzdist, which could be used for this. IMO this could be a
good companion to NTP (or even PTP) because it can provide leap second
warnings and TAI offsets, but also time zone rules, which is also very
important for user space applications.

> smeared. Or like the current draft that you have smear offset.

AFAIK, the original reason to do smearing is to completely hide a leap
second from the clients.

For example, we had customers running a certified Linux system with a
known bug that the kernel locks up when it inserts a leap second. Due to
the certification, the customer was not even allowed to update the Linux
kernel, even though a kernel with a bug fix was available.

So they used a smearing server to hide the leap second and prevent the
kernel from lockup.

With this in mind, I think the best approach would be to let a server
provide smeared time, with an optional information about the current
smear offset, so clients could optionally compensate the smearing.

ntpd from ntp.org currently provides the current smear offset in a
special interpretation of the refid field, if smearing is in progress.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
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

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 8 Dec 2020 19:01:52 +0100

> leap second, for a total of 3 seconds.

AS said earlier, ntpd from ntp.org does this. It sets the leap bits to
"unsynchronized" so the client sees that it gets a reply, but (with
usual poll intervals) a single reply to be dropped.

This avoids huge time offsets that could occur e.g. if the kernel steps
the time back just after the server has grabbed a receive timestamp for
a request, and before it grabs another timestamp as the transmit time.

> devices that do care about it, have the option to get it, but

As far as I can tell, most NTP clients just run fine if they receive a
leap second warning from the server early enough.

What happens at the client side if the kernel just steps the time back,
and if e.g. databases get a hickup because the time is stepped back is
IMO a problem of the operating system and the applications, which in
fact goes back to the deficiencies of the POSIX time specification.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 8 Dec 2020 19:18:40 +0100

> How do you suggest it should be called?

In fact, it's like POSIX time but with a different epoch. Is POSIX time
UTC? ;-)

I've seen other programming environments where time_t directly returned
seconds since 1900, not 1970. If I remember correctly, LabWindows CVI is
such a system.

> That's a good point. It would help have a special value, or a flag,

In the past, the reason for the problems with leap second announcements
were firmware bug in GPS receivers (or in ntpd in one case).

So when would that special value be used?

In case if a leap second file is available, but has expired?

In case a GPS receiver is used but it is impossible to retrieve the leap
second/TAI info from the receiver? For example, as far as I know there
is no NMEA sentence that transports the leap second / TAI information
that is available inside the receiver.

> actually updated to request it? I doubt it.

I agree. As mentioned earlier, this is used to send faked time to the
clients to totally hide the leap second.

If a client was aware that it couldn't handle a leap second properly, it
could do the smearing by itself, locally.

Using a smearing server makes thing easier because there's only the
server that needs to be modified, and all clients of that server behave
in the same way.

> the case when it knows about the leap second from a separate source.

As said earlier, ntpd from ntp.org already sends a special refid while
sending smeared time, so "intelligent" clients already could detect and
compensate the smearing.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 8 Dec 2020 19:31:16 +0100

> strftime() works with a struct tm, so can work in UTC.

Right, and the problem is that protocols like NTP or PTP (and their
implementations) have to cope with the limitations of those specs.

I don't believe that this can be handled at the time synchronization
protocol level. That only shifts the reason of the problems to some
slightly different location.

> possible to work in TAI or UTC on Linux, it's just that most

But in any case you first need to have a trusted source for the TAI
offset, so some program can send it down to the kernel.

By the way, if you start a Linux kernel and the TAI offset has not been
set by some program, the kernel reports TAI offset 0.

However, when the kernel receives a leap second warning from an NTP or
PTP daemon, and it inserts a leap second, the kernel increments its TAI
offset when the leap second is inserted.

To the kernel reports TAI offset 1 after it has observed a leap second,
which is obviously wrong, but it shows that you can't simply check if
the TAI offset is 0 if you need to know if the kernel knows the real TAI
offset.

Tricky, all this stuff.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 21:07:46 +0100

> the TAI offset is 0 if you need to know if the kernel knows the real TAI

If you want to work in UTC, yes you need a trusted source of the
offsets. Assuming you do have that, you can check that the kernel
has it set correctly. If it's not correct, there are some options,
for example setting it if you have permissions, switching to POSIX
time, or returning an error.

We seem to be getting a little of topic.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 8 Dec 2020 21:32:15 +0100

> month when Circular T is published for this month.

Whatever value is used in NTP, it's never the true value, it's
always an estimate. The TAI value we would use is an estimate of
TAI with error bounds. If BIM is off by 12 us, and BIM is used as
a source for NTP, they can either compensate for that 12 us, or add
the 12 us in the error calculation.

If the 12 us difference is important, I suggest they use an
extention to distribute that 12 us.

Kurt

---

From: Steve Allen <[email-masked]>
Date: Tue, 8 Dec 2020 12:49:40 -0800

On Tue 2020-12-08T21:32:15+0100 Kurt Roeckx hath writ:
> always an estimate.

Please explain this in the document.

> The TAI value we would use is an estimate of

Rather than TAI I suggest TAI-like, specifically with a parameter N that
allows the time scale to be N seconds different than TAI.
Particular values of N would be

TAI -  0        attempting to match what TAI should be
TAI - 10        the POSIX time_t value used for IANA tz "right" zones
TAI - 19        the source is GPS system time or Galileo system time
TAI - 33        the source is BeiDou system time
TAI - 37        the source is Windows10 system time (after 2017-01-01)
TAI -  N        this futureproofs for the next purely atomic source of time

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 07:52:22 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 08.12.2020 um 12:05 in Nachricht

Hi!

So your poposal is that an NTP implementation passes struct tm directly to the
application? And how will the application get the time when the NTP service is
not running?

You may be right in your arguments, but it really does not solve the problem.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 08:00:04 +0100

Hi!

Can you be more specific? I only see:

           struct tm {
               int tm_sec;    /* Seconds (0-60) */
               int tm_min;    /* Minutes (0-59) */
               int tm_hour;   /* Hours (0-23) */
               int tm_mday;   /* Day of the month (1-31) */
               int tm_mon;    /* Month (0-11) */
               int tm_year;   /* Year - 1900 */
               int tm_wday;   /* Day of the week (0-6, Sunday = 0) */
               int tm_yday;   /* Day in the year (0-365, 1 Jan = 0) */
               int tm_isdst;  /* Daylight saving time */
           };

The practical reason when POSIX does not specify the length of a second seems to allow clocks with errors; demending that  it's an SI second yould pose relly trouble on implementers I'm afraid.

Regards,
Ulrich

> time. The clock_gettime() function you mentioned has TAI support.

Again, can you be more specific. I only see:

       The  res  and  tp  arguments  are  timespec structures, as specified in
       <time.h>:

           struct timespec {
               time_t   tv_sec;        /* seconds */
               long     tv_nsec;       /* nanoseconds */
           };

And the letters TAI appear nowhere in the description.

> possible to work in TAI or UTC on Linux, it's just that most

And when not using Linux?

Regards,
Ulrich
[...]

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 08:29:10 +0100

>>> Steve Allen <[email-masked]> schrieb am 08.12.2020 um 17:44 in Nachricht
<[email-masked]>:
> On Tue 2020‑12‑08T10:31:04+0100 Miroslav Lichvar hath writ:
> Metrology (BIM) has had UTC‑UTC(BIM) values around 12 microseconds

This reminds me of "clock hopping" issues: I think with higher precision
"clients" the issue becomes more evident, and I'm not sure what the perfect
solution against the problem is. Maybe the specification should talk about
that, too.
I'm attaching an example that (I think) shows clock hopping (mostly between
two sources, using GPS and DCF-77, respectively).

> ‑‑
> Steve Allen                    <[email-masked]>              WGS‑84 (GPS)
> UCO/Lick Observatory‑‑ISB 260  Natural Sciences II, Room 165  Lat 
+36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng
‑122.06015

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 08:40:58 +0100

>>> Martin Burnicki <martin.burnicki=[email-masked]> schrieb am
08.12.2020 um 18:29 in Nachricht
<[email-masked]>:

(I agree with Martin's points)

...
> systems just step the time back by 1 second to insert a leap second.

And the POSIX calls, while allowing "second 60" actually fail to return such as the kernel API cannot (AFAIK) provide the information necessary. In a perfect word "second 60" would be returned even when no NTP client is running on that machine.

...

> provides invalid information?

Before that, define how to detect that a trusted source is providing invalid information ;-)

...
> timestamp is some local time, but an offset allows to determine the

But most notably those email time stamps lack information about the local clock error ;-)

...
> special interpretation of the refid field, if smearing is in progress.

Another "quick fix"...

Regards,
Ulrich

---

From: Warner Losh <[email-masked]>
Date: Wed, 9 Dec 2020 08:42:32 -0700

>                int tm_isdst;  /* Daylight saving time */

time_t encodes 23:59:60 Dec 31 and 0:0:0 Jan 1 with the same number (when
converted from struct tm, POSIX is actually silent on how to encode the
leap second because it doesn't acknowledge the leap second exists). POSIX
ignores leap seconds. This fiction of 60 here is woefully incomplete.
struct tm isn't really used for anything but presentation... These issues
have been extensively litigated, discussed and explained in the
LEAPSECONDS list.

> The practical reason when POSIX does not specify the length of a second
> seems to allow clocks with errors; demending that  it's an SI second yould
> pose relly trouble on implementers I'm afraid.
>
> Regards,
> Ulrich
>

You might look at the CLOCK* defines. You'll find TAI there.

> And when not using Linux?

FreeBSD works too, or has in the past.

Warner

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 9 Dec 2020 19:49:22 +0100

> application? And how will the application get the time when the NTP service is

NTP normally doesn't pass things to the application. NTP and other
applications talk to the kernel. If you have something that does
does support UTC, like a text format, or use an interface to
the kernel that is not in POSIX time, you can convert it to a
struct tm that knows about the leap seconds.

>                int tm_isdst;  /* Daylight saving time */

Note that tm_sec is 0-60, not 0-59. It even at some point has
support for 0-61.

You can not use something like gmtime() to fill in that struct tm
if you want to be able to have tm_sec set to 60. But if you write
your own function to fill in the struct, it can be used.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 9 Dec 2020 19:51:39 +0100

>                long     tv_nsec;       /* nanoseconds */

man clock_gettime() has:

       CLOCK_TAI (since Linux 3.10; Linux-specific)

              A nonsettable system-wide clock derived from
wall-clock time but ignoring leap seconds.  This clock does not
experience discontinuities and backwards jumps caused by NTP
inserting leap seconds as CLOCK_REALTIME does.

              The acronym TAI refers to International Atomic Time.

In case you use CLOCK_REALTIME, the tv_sec will be in POSIX time,
if you use CLOCK_TAI, it will take the leap seconds into account.

Kurt

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 9 Dec 2020 23:44:36 +0100

Warner Losh wrote:
> time_t encodes 23:59:60 Dec 31 and 0:0:0 Jan 1 with the same number
> (when converted from struct tm, POSIX is actually silent on how to
> encode the leap second because it doesn't acknowledge the leap second
> exists). POSIX ignores leap seconds. This fiction of 60 here is woefully
> incomplete. struct tm isn't really used for anything but presentation...
> These issues have been extensively litigated, discussed and explained in
> the LEAPSECONDS list.

Right. If "someone" happens to put a "60" into the seconds field, the
user can see that this specifies an *inserted* leap second.

I wonder how that structure could be used to indicate a *deleted* leap
second, of which I hope it will never occur. ;-)

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 10 Dec 2020 08:46:07 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 09.12.2020 um 19:49 in Nachricht
<[email-masked]>:
>> >> need to specify some use‑level API how to get the current time:
>> >> time()
>> >> gettimeofday()
>> >> clock_gettime()
>> >> localtime()
>> >> strftime()
>> >> 
>> >> They all assume UTC... It's rather useless if NTP has the exact time,
but 
> no

Once again in other words: How does the leap second knowledge come "out of
NTP" (into kernel or application) when you do not specify an operating system
clock model? The discussion so far is how to get the leap information back "out
from the OS kernel".

>> So your poposal is that an NTP implementation passes struct tm directly to

> the
>> application? And how will the application get the time when the NTP service

> is
>>                int tm_sec;    /* Seconds (0‑60) */
>>                int tm_min;    /* Minutes (0‑59) */
>>                int tm_hour;   /* Hours (0‑23) */
>>                int tm_mday;   /* Day of the month (1‑31) */
>>                int tm_mon;    /* Month (0‑11) */
>>                int tm_year;   /* Year ‑ 1900 */
>>                int tm_wday;   /* Day of the week (0‑6, Sunday = 0) */
>>                int tm_yday;   /* Day in the year (0‑365, 1 Jan = 0) */
> Note that tm_sec is 0‑60, not 0‑59. It even at some point has
> support for 0‑61.
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 10 Dec 2020 08:50:31 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 09.12.2020 um 19:51 in Nachricht
<X9Ecu6dcweW/[email-masked]>:
>>        The  res  and  tp  arguments  are  timespec structures, as specified

> in
>        CLOCK_TAI (since Linux 3.10; Linux‑specific)

Actually for glibc-2.22 I don't see that documented, while I see the define in
the kernel includes:
# find /usr/include/ -type f  | xargs grep CLOCK_TAI
/usr/include/bits/time.h:#   define CLOCK_TAI                   11
/usr/include/linux/time.h:#define CLOCK_TAI                     11

> 
>               A nonsettable system‑wide clock derived from
> wall‑clock time but ignoring leap seconds.  This clock does not