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
