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.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
