Re: Predictable Internet Time

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Apr 21, 2017 at 2:41 PM, Joe Touch <[e-mail]> wrot
​e​

> On 4/21/2017 11:35 AM, Phillip Hallam-Baker wrote:
>
> ​To answer the issues raised:
>
> 1) POSIX already has this pretty much covered
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html
> ​
>
> ​int clock_gettime(clockid_t *clock_id*, struct timespec **tp*);​
>
> ​So all that is required is to define clock identifiers for:
>
> TAI (The total number of seconds elapsed since the start of the epoch)
> UTC (The TAI value adjusted for UTC leap seconds, i.e. number of non leap
> second seconds since the start of the epoch)
>
> If these aren't already included, I'm surprised (at least UTC).
>

​Well I linked to the spec so you could have looked and checked. You are
wrong. The spec is ambiguous as to whether the value is UTC or not, hence
the need to be explicit. ​



>
> PIT (The TAI value adjusted for PIT leap seconds)
>
>
> We don't need PIT.
>
> ​That is your opinion, like the astronomers, you might just be wrong about
the requirements.

I can see the benefit of an IoT where time is absolutely predictable even
if it may be out of sync with UT by a few seconds.​ You might not but I
doubt you have the range of experience in realtime and process control that
I have.

​Unless a device actually deals in time, PIT is going to be just fine for
status messages and logs. The advantage over UTC being that you know
exactly what the device is trying to do which you don't have with UTC. You
don't know whether the device is keeping UTC or some heuristic.

TAI would be a possibility if we counted in seconds which we don't. We
track time by date and need to compare. The difference between UTC and TAI
is half a minute which is just too much to be viable.​


POSIX already defines constants for CLOCK_PROCESS_CPUTIME_ID, CLOCK_REALTIME
>
>
> All that is needed is to define the additional ones.
>
>
> ​2) No I did not move the goalposts. My original proposal was to solve the
> needless chaos caused be the idiotic notion of changing the definition of
> time at six months notice. The stupidity of that notion should be apparent
> to all.
>
>
> There is no getting around the fact that the rest of the planet accepts
> leap seconds. If that's not something you want to track, then use TAI and
> be off-sync with the rest of the world when they use UTC.
>

​Since the standard was only created in our lifetimes, it is hardly
immutable and fixed for all eternity.

The reason UTC is the standard is because it is what the ITU decided to use
and the broadcasters synchronize everything. That can change.