On Fri, Apr 21, 2017 at 2:41 PM, Joe Touch <touch@xxxxxxx> wrot
e
On 4/21/2017 11:35 AM, Phillip Hallam-Baker wrote:If these aren't already included, I'm surprised (at least UTC).To answer the issues raised:
1) POSIX already has this pretty much covered
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)
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.