Timescales and how they apply to TimeKeeper

There are many timescales in timing (PTP, NTP, GPS, TAI, UTC, etc.) but most practical timekeeping is based on UTC (Coordinated Universal Time). Regardless of what timescale applies to the time delivered to TimeKeeper, it distributes time in UTC.

PTP and TAI/UTC

PTP may be distributed in different timescales, including the 2 common scenarios below which are of interest to TimeKeeper:

TimeKeeper can consume time according to either timescale and will convert to UTC as needed. When serving time it will deliver PTP in UTC. This means that clients getting PTP from TimeKeeper will get time with a reported 0 offset to UTC reported as it’s already natively in that timescale.

This is rarely an issue although some clients that assume all PTP is delivered in TAI with a UTC offset. These clients may note/warn if the UTC offset is 0. In general these are just warnings but please contact the vendor for specific concerns. In some cases particular devices can get accurate time via NTP and optionally a PPS if they’re unable to use UTC-based PTP directly.

UTC offset being ‘reasonable’ or traceable

In some configurations the timescale may be unrelated to any external reference, isn’t matched to UTC in any way, or might be intended to be relevant to UTC but is no longer traceable to it.

PTP packets indicate whether the delivered time is reasonable relative to UTC. By default, if the PTP TimeKeeper sees doesn’t indicate it’s reasonable/traceable to UTC, TimeKeeper won’t use that PTP and that TimeKeeper source won’t be active. This is to protect against using invalid or untraceable sources of time.

Hoever, if this configuration is intended or expected, TimeKeeper can be configured to accept that PTP feed. Any TimeKeeper source that should accept PTP without being traceable to UTC should set ALLOW_UNREASONABLE_UTC=1 in the source definition. The rest of the configuration details are covered in the “Configuration” section.