Re: [art] Predictable Internet Time

[Nico Williams <[e-mail]>]

On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote:
> >> time_t does not access a SI reference or frankly any other stable reference.
> > The Open Group man pages I'm looking at don't reference SI, but so
> > bloody what.  If it says "seconds", it means "seconds".
> That's the trouble - seconds in SI are not seconds defined as 86400/day.
> If the units don't match,  then a conversion needs to be included. If
> the units aren't known, you can't convert accurately.

POSIX does NOT define seconds in terms of days!  It does the opposite:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16

    How any changes to the value of seconds since the Epoch are made to
    align to a desired relationship with the current actual time is
    implementation-defined. As represented in seconds since the Epoch,
    each and every day shall be accounted for by exactly 86400 seconds. 

There is NO reference to solar or sidereal days or any other
astronomical definition of day.

Unlike as with days, there is no multiplicity of generally accepted
definitions of seconds, so there is no support for the idea that this
text defines seconds in terms of days.

The second sentence defines days in terms of seconds, not the other way
around.

The first sentence is a bit abstruse, but no matter, because in
_practice_ on all systems I know of that claim to implement POSIX, or
which don't but which are Unix or Unix-like systems, seconds since the
epoch differs from UTC *only* by leap seconds -- just like TAI.

Also, POSIX does refer to UTC:

    A value that approximates the number of seconds that have elapsed
    since the Epoch. A Coordinated Universal Time name (specified in
    terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days
    since January 1 of the year (tm_yday), and calendar year minus 1900
    (tm_year)) is related to a time represented as seconds since the
    Epoch, according to the expression below.

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 text is sufficiently ambiguous (because of its errors, for example)
that you could remotely plausibly make these claims that you do, but
practice does not bear them out.

> > It's very safe to assume it's 1.  Anything else would be insane.
>
> s/insane/undefined/
> 
> That's the problem. I appreciate it would be nice if there were a
> definition (as a start), and if the defined unit were SI, but it isn't,
> AFAICT. If you have a ref to the contrary, I'd be more than glad to
> include it and correct the doc accordingly.

POSIX seconds are not defined, indeed, but they can only be taken to be
SI seconds -- anything else would be sheer madness and, anyways, not
supported by actual practice.  I know of no POSIX or POSIX-ish system
where this is not true.

Running code, _running code_.

> > Isn't that the important bit of information here?
> 
> To you and me, perhaps, but there are others on this thread that are
> misled by what POSIX is and how easy/hard it is to convert to TAI/UTC...

Maybe, but so are you.  Not that that is particularly important to
making a successful argument against smearing, but that such errors are
distracting.

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.

Nico
--