[LEAPSECS] Running on TAI

[Martin Burnicki]

Hi all,

Rob Seaman wrote:
> Our Meinberg ref clocks can deliver GPS, UTC, or TAI (and thus other
> derived timescales).

Yes, and the same data formats are used for each of these time scales.


Just a few general thoughts based on an internal note, instead of
replies to individual posts here on the list:

IMO you have to generally distinguish between specific data formats, and
the type of information a particular data type can contains.

For example, the 32:32 bit timestamp type used in NTP packets has been
specified to provide UTC. But of course, if you configure your
timeserver for a different time scale than UTC then it just transports
"a time" according to the configured scale.

I'm sure that even the UT1 NTP server operated by NIST puts a UTC
timestamp into those fields.

The same applies to the time_t type, IMO. If you let the system kernel
run on TAI or whatever then the time() function still returns a time_t
data type, but its value represents TAI or whatever has been configured.

Even if you have separate API calls that either return TAI, UTC, or
whatever from the kernel you can use the same data format for the
returned timestamps.

In fact, clock_gettime() always returns the same data type (struct
timespec, which includes a time_t field), but the type of information
differs depending depending on the specified clock ID, and may be a UTC
time, a number of seconds and nanoseconds since boot, or whatever.


IMO the basic problem is in many cases that some extended information is
missing. For example, if you receive an NTP packet you are basically
unable to distinguish if the time in the packet is really UTC, or
something else. However, if you know that the packet originates from a
UT1 server you can assume that it transports UT1 rather than UTC.

Similar with time_t. If you read timestamps in a fast loop across an
inserted leap second you can only distinguish times if you have a leap
second status flag associated with the time, so when kernels simply step
the time back to insert a leap second you don't know if the "UTC
midnight" timestamp is represents the original second, or the repeated
second, which is in fact the leap second.

This is similar to the end of DST, where a pure hh:mm:ss time doesn't
tell if it belongs to the first hour, or to the repeated hour. You know
this only if you can retrieve the DST status with the time in a
consistent way, so the first time has DST enabled and the repeated time
has it disabled.

Even if a DST flag is available (e.g. in struct tm), you don't know from
the information from the structure alone if the time the structure
contains is UTC, or local a time according to whichever time zone has
been configured.


Generally it makes a difference whether you simply need the current time
which steps when a leap second is applied to UTC, or when DST changes
for local time, and continues ticking normally after that event, or if
you have to deal with time *intervals*.

If your application deals with time *intervals* then it has to be aware
that the day is one second longer than usual if a leap second has been
inserted, and in local time even one hour longer at the day when DST
ends. I think developers more often care about DST steps than leap
second steps because DST steps simply occur more often, in shorter
intervals.


If you need to convert GPS time or TAI to UTC, or vice versa, then of
course you need some source of information that tells the current
UTC/TAI or UTC/GPS offset. This is also the case if your kernel runs on
TAI. There are different possible sources which provide different amount
of information.

For "current" times the information that can be provided by the NTP or
PTP protocol, or from a GPS receiver, is sufficient.

However, if you need to deal with historic time intervals then a leap
second table is required which explicitly tells at which points in time
leap seconds have been inserted. This is just similar to dealing with
historic local times, where the TZ DB provides information if and when a
DST changeover occurred in the past.

Neither GPS, nor PTP or NTP provide this historic information, but e.g.
the TZ DB also includes a leap second table, or you can get the leap
second file directly from the sources (IERS, NIST, USNO, ...).

The problem here is that a leap second table as well as the TZ DB has to
be kept up-to-date by some means, since upcoming changes can't be
predicted automatically.

This requirement is not only for TAI/GPS to UTC conversion. Also if you
need to derive e.g. UT1 from TAI, GPS or UTC you have to provide some
information (e.g. a data file) how the UT1 offset develops over time,
and this information has to be updated in regular intervals.


Sorry for the long post which just tries to summerize a couple of things.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at 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