Hello Petr,
AFAICT, the UNIX "epoch time" is per definition oblivious of leap
seconds = in UNIX time, leap seconds "do not exist, and after a leap
second actually happens, to a UNIX machine it never has happend" :-)
This approach is probably standardized in POSIX.
http://www.madore.org/~david/computers/unix-leap-seconds.html
=> the Linux kernel actually seems to an official API
which can be used to step the time on a leap second.
It consists of two attributes within the arguments of adjtimex(),
called STA_INS and STA_DEL.
https://lwn.net/Articles/648313/
http://man7.org/linux/man-pages/man2/adjtimex.2.html
>From a recent trouble issue with an outdated ntpd release (in Linux),
when I was watching leap second transitions on peerstats and
loopstats graphs, it seems that even ntpd (who does know about leap
seconds for sure) has to adjust the Linux system timebase either
gradually or possibly stepwise to "correct for" the leap second that
has actually just occurred.
https://access.redhat.com/articles/15145
https://developers.redhat.com/blog/2015/06/01/five-different-ways-hand
le-leap-seconds-ntp/
=> the traditional wisdom that "UNIX system timebase runs in UTC"
has an exception: the leap seconds are not systematically accounted
for. Leap seconds get skipped or smeared, and finally: ignored.
If you want a timestamp that does *not* include ignored leap seconds,
you would probably have to keep an eye on the official
leap seconds list
https://www.ietf.org/timezones/data/leap-seconds.list
or poll the local ntpd instance via ntpdc
or keep an eye on the flags in adjtimex (in the kernel)
and add the leap seconds on your own.
And, if your system is configured to handle leap seconds by
smearing/slewing, you would have to know that your timestamps are
fuzzy for some minutes or hours following the actual leap.
PTP's native time scale is the "TAI": an international standard
counting SI seconds. TAI does not add or subtract leap seconds, nor
does it accommodate them in any way, it just runs forever with 60
seconds per minute precisely - this works well for various machine
synchronization purposes where unambiguous and continuous time is
vital.
TAI has a certain offset against the UTC, and this is transported in
PTP as an "additional attribute", called simply the UTC offset.
It's up to the PTP slave/client to decide how to process that
information internally: the PTP timestamp + the UTC offset
+ possibly the daylight saving offset.
Note that the TAI time scale is similar to the GPS time scale
in this respect (continuity), but these two (GPS and TAI)
have a different "UTC offset".
https://www.google.cz/search?q=GPS+UTC+TAI
=> If you have access to a PTP GM, your best bet might be
to use a NIC with PTP support in HW (= one containing a PHC)
and ask the NIC hardware for accurate timestamps :-)
independent of the UNIX epoch timebase in the host OS.
NTP does carry leap second announcement ahead of the actual leap.
Any serious "atomic clock" serial time string does carry that
information as well (I'm familiar with the Meinberg Standard Time
String).
The GPS satellite segment does transmit a current GPS-to-UTC offset
information *and* an announcement ahead of the actual leap.
https://www.meinbergglobal.com/english/info/leap-second.htm
I haven't found any clues if any specific announcement flag or
something is available in the NMEA data format.
Frank
On 15 Jan 2018 at 11:17, Petr Kulhavy wrote:
>
> Hi,
>
> my question is not directly related to linuxptp, but the expertise here
> might be the right one to answer it.
>
> Is there a way to retrieve a UT1 timestamp on Linux? It seems all the
> library functions like gettimeofday(), clock_gettime() etc. return the
> Unix time without leap seconds.
> And the library functions that do handle leap seconds always work with
> the broken-down time (e.g. localtime(), gmtime())
>
> Does PTP transmit the leap second information?
>
> Thanks
> Petr
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel