Re: [art] Predictable Internet Time

[Philip Homburg <[e-mail]>]

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

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

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

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

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. If tm_sec == 60, i.e. during a leap second, you get the same
time_t value as the first second of the next minute.

>> - 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. Ntpd will hapily
step the (POSIX) time backwards. So you need a separate clock, which POSIX 
calls CLOCK_MONOTONIC (see clock_settime).

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

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

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

> - broken-down time without leap seconds

Not sure why that would be desirable, but that's what have now.

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

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