Re: [art] Predictable Internet Time

[Joe Touch <[e-mail]>]

On 3/29/2017 4:36 AM, Philip Homburg wrote:
> [Just responding to text in many different e-mails]
>
>>> actual solar time is extremely rare (only sundials). Solar time is almost
>>> always mean solar time. I.e UT0 is already mean solar time.
>> Section 3 states that in the definition of a solar day. Section 4.2
>> explains that UT0 is one of many different "means", and that UT0 is the
>> most common in current use.
> Very confusing to have two completely different definitions of Solar day in one
> item. Later you use solar time sometimes as mean, sometimes as 'apparent'.

That's on my list to fix (I'm typing that summary to post to the list in
a minute or two)...
>
>>>   This makes a statement that GPS time differs 25 ns from TAI a bit weird.
>>>   Maybe this is too much detail. 
>> See above - even in retrospect, GPS can differ from TAI by 25 ns (it's
>> in the spec for GPS). GPS isn't one of the clocks averaged into TAI
>> (AFAICT); it's a separate source that's sync'd to TAI to ensure the 25
>> ns max delta.
> Given the complexities of dealing with time at the nanosecond level, maybe
> it is better to ignore those issues in this document. I.e, GPS and Galilelo
> are synced to TAI (with some fixed offset). GLONASS tracks UTC. And leave it
> at that.
>
>>> - It is not clear to me why NTP would differ 100ms from TAI.
>> It's in the spec.
> Can you be more specific.

I'm tracking that down - it's because of the strata.

>
>>> - It is not clear to me what 'Unix time' is in this context. Typically POSIX
>>> time is linked to UTC, 
>> That is incorrect. POSIX time is defined as 1/86400 of a day, which does
>> not take into account leap seconds at all (UTC does) and "day" is not
>> defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at
>> best a rough approximation of UT0.
> I was going to propose that for this document we treat POSIX time as
> NTP time minus 2208988800. Unfortunately, the latest NTP RFC (5905) doesn't
> seem to actually define NTP time. So that doesn't help.

I think I see the issue here.

Unix time is a count since epoch, but never defines second or day. It
emulates TAI, but there's no definition of how it drifts (or not) from TAI.

POSIX *time* is this Unix time.

The POSIX time API allows access to two different clocks: a local
realtime clock and a local monotonic clock. The API *approximates* UTC
by trying to convert its internal time to what it thinks is UTC. When
that realtime clock is updated by NTP, the API can present an accurate
UTC value. When not, it likely presents something that is TAI+offset,
because it doesn't track leaps.

It's important to differentiate these; I've been talking almost
exclusively about POSIX *time*, not the POSIX time API.

>
>> But as others have pointed out, that is either a lie or an error: POSIX
>> simply does not and cannot account for leap seconds in a numeric type
>> representing seconds since an epoch.  Perhaps we can say that the
>> reference to UTC was meant to be to TAI.  Either way the definition of
>> seconds can only plausibly be SI.
> The way I read it, the following formula
>
> tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
>     (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
>     ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>
> converts between a time_t value and a broken down UTC time. 
See above. This is just an *approximation* that tries to convert Unix
time to something close to UTC, but because it doesn't track leaps, it
really emulates TAI.


> Just about
> every piece of software assume this to be true. I.e, if you run ls then
> the times shown by ls are based on this formula.
>
> Of course this implies that time_t is horribly broken in many different ways,
> but we already know that.
If time_t is an integer (i.e., you're not referring to the struct tm or
some other API), then it is supposed to be the Unix time...

> So if you subtract two time_t values, you don't get the real number of
> seconds between the two points of time they represent because leapseconds
> are ignored. 
You do (or should) get the real seconds.

You can't subtract two struct tm's that way, though.

>
>>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
>> Uptime is just a printout of the delta of the POSIX time when a computer
>> started and the current POSIX time.
>>
>> It might be useful to indicate that some computers just start their
>> clocks at boot as zero.
> The main thing is that monotonic time can never go backward. 

It can on reboot.

> Ntpd will hapily
> step the (POSIX) time backwards. So you need a separate clock, which POSIX 
> calls CLOCK_MONOTONIC (see clock_settime).
We really need to differentiate between the POSIX time scale and the
POSIX time API. You're talking about the POSIX time API. POSIX time
itself should never go backwards...

>
>> I can add a new "monotonic clock" definition that uses an arbitrary
>> "tick" that is guaranteed to increase between reads and across reboots,
>> but is not comparable across machines.
> Note that monotonic time is typically not maintained across reboots.
I'll point that out too..

>
>> Better data types -and strong typing- are needed:
>>
>> - Unix-like TAI (seconds since epoch, admitting not leap seconds)
> If we can get the opengroup to add CLOCK_TAI then we can have this. One
> problem is that there doesn't seem to be a sensible epoch for TAI.
TAI defines its epoch as 1977-01-01

When you say "sensible", is the problem in representing times before
that epoch? They can be denoted as negatives...

>
>> - Unix-like UTC (seconds since epoch, with leap seconds)
>>    - both with variations like real versus integer, or seconds +
>>      microseconds, etc..
> I'd like to treat time_t as something that is synchronized with UTC and behaves
> rather weird around a leap second.

time_t should be the Unix time, which can't sync to a time scale with
leaps like UTC

the POSIX time API does have a struct tm, which might derive a UTC
approximation.


>
>> - broken-down time with    leap seconds
> A 'tai_gmtime' could do that.
>
>> Then there's intervals.  Having variations on intervals based on whether
>> or not they admit leaps seems silly though, so intervals are a bit
>> easier.
> If you want to set a timer based on an interval, then it may make sense to
> know if leap seconds need to be counted or not.
That would depend IMO on whether the timer is supposed to trigger on an
exact date or at the end of an exact interval. That's worth noting.


>
>> The obvious argument against smeared time is that we already have _two_
>> time standards, and we don't need a third.  All we need is to carefully
>> pick one or the other in each specification, and preferably TAI time in
>> all cases.
> There is (right now) no meaningful way to convert 2020-01-01 00:00:00 UTC 
> to a TAI time value.

True, but that's also because that UTC date is indeterminate.  Until you
know the leaps between now and then, you don't know when that date will
actually occur.

Joe