Re: [Ntp] Antw: [EXT] Re: Timescales

[Magnus Danielson <[e-mail]>]

Martin,

On 2020-12-10 00:10, Martin Burnicki wrote:
> Magnus Danielson wrote:
>> Hal,
>>
>> On 2020-12-09 20:02, Hal Murray wrote:
>>> [e-mail] said:
>>>> Most computers work primarily in UTC.
>>> Most computers work on POSIX pseudo UTC time.
>>> (which is why we have this leap-second mess)
>> Most computers use one of two interpretations of POSIX Time.
>>
>> One variant of UTC to POSIX time_t mapping was provided for a while, but
>> later removed from the POSIX documentation, mapping 23:59:60Z into
>> 00:00:00, which is what you expect from (omitting date)
>>
>> time_t = hours*3600 + min*60 + sec
>>
>> and as this is re-interpreted as print-out time
>>
>> sec = time_t % 60
>> min = (time_t / 60) % 60
>> hour = (time_t / 3600) % 24
>>
>> reads out as 00:00:00, which next section also labelled 00:00:00. This
>> behavior is mimiced by the NTP time-scale for at NTPv3 and NTPv4 as I
>> recall it.
> The problem is that there is no status flag. For example, if you read a
> POSIX-like timestamp from a Meinberg PCI card, there are API calls that
> also include a status word, and while one of the status bits tells that
> a leap second is approaching, another bit tells that the current second
> is a leap second, so you can properly solve the ambiguity if you
> evaluate the status flag.

Agreed. This is why I think one should look at other interfaces to get
the time, such that sufficient information is available. If you use
ntp_gettime() for instance you get considerable more meta-data. Also,
you can get time-stamps in CLOCK_TAI for instance for some OSes.

In general, I think we should make people aware of such solutions, make
sure they functions and promote their proliferation.

Cheers,
Magnus