KB2021.328
Determining TAI-UTC Offset options
This article applies to Domain Time II.
Last Updated: 28 Mar 2021
The PTP IEEE-1588/2019 specification requires that master clocks indicate what timescale to use when interpreting timestamps.
Timestamps are provided in TAI (International Atomic Time). UTC (Coordinated Universal Time) is based on TAI, but offset by
the current number of leap seconds needed to compensate for changes in the Earth's rotational speed. PTP uses the Announce packet
to indicate whether the time is using the PTP timescale (ptpTimescale), and if so, what offset to use to calculate UTC time and
if that offset is valid. Unfortunatly, PTP masters often vary in their implementation of these settings.
Announce timescale options
If the Announce packet are marked as PTP timescale, this normally means that timestamps will be in
TAI, and an offset must be subtracted to derive UTC. For example, as of March 2021, TAI is ahead of UTC by 37 seconds.
This number changes with each new leap second.
If the Announce packets are marked as ARB timescale, by convention only, this means timestamps
are in UTC. 1588 provides no meaning for any setting other than the PTP
timescale with TAI-UTC offset information included. Any timescale at all
is possible, with no setting in 1588 to tell you which. An Announce that
advertises the ARBitrary timescale must be sending UTC timestamps, else
your clock will be wrong. In this case, no UTC offset should be applied.
UTC Offset variables
The Announce packet has two other variables, a flag "currentUtcOffsetValid"
(sometimes called "utcOffsetReasonable"), and a 16-bit signed integer,
currentUtcOffset. If an Announce says it is using the ptpTimescale, but
either the currentUtcOffsetValid flag is false, or if the currentUtcOffset
value is zero, then the timestamps are presumed to be UTC instead of TAI.
It is possible to configure a master to serve TAI timestamps, but not set
the corresponding flags to provide TAI-UTC offset information. This type
of configuration is forbidden by 1588-2008 and 1588-2019. The only way to
obtain the correct time of day from such a master is for the slave to
know and apply the missing TAI-UTC offset information, which is outside
the scope of 1588, and considered a misconfiguration of the master.
Overriding incorrect or missing offset information
DTClient (Windows), DTServer (Windows), and DTLinux (Linux) allow you to
override the (or provide the missing) currentUtcOffset value.
On Windows, you must set two registry
values found in the
setting in dtlinux.conf.
These settings allow you to compensate for a misconfigured master that sends TAI
timestamps without also providing the TAI-UTC offset (or old hardware
that provides the wrong TAI-UTC offset).
If an override is provided, Domain Time will use it, and treat timestamps
as TAI. If an override is not provided, Domain Time will use the Announce
packet's information to determine if the timestamps are TAI or UTC.
Other possible master configurations
Many grandmasters set the ptpTimescale and currentUtcOffsetValid flags to
true, but set the currentUtcOffset value to zero (or just set the
currentUtcOffsetValid flag to false, regardless of the currentUtcOffset
value). This is equivalent to announcing that it is not using ptpTimescale,
and the only possible interpretation of the timestamps is UTC. In this case,
you should set Domain Time to set the TAI-UTC offset to zero.
Some masters allow either the currentUtcOffsetValid flag to be false, or the currentUtcOffset
value to be zero. This violates the 1588 standard, but convention
says it means the timestamps are in UTC, and that the TAI-UTC offset
does not apply. If the master is actually sending TAI timestamps,
you must use the override procedure, else your clock will be wrong
by the current TAI-UTC offset value. In this case, you should set Domain Time
to use the current correct TAI-UTC offset.