On 4/21/2017 1:29 PM, Phillip Hallam-Baker wrote:
On Fri, Apr 21, 2017 at 2:41 PM, Joe Touch <touch(_at_)isi(_dot_)edu
<mailto:touch(_at_)isi(_dot_)edu>> 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
<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 linked to an outdated 2004 spec.
The current spec is here: http://pubs.opengroup.org/onlinepubs/9699919799/
You are wrong.
I can't be wrong. I said "IF", and you can't claim I'm not surprised
that these aren't already included.
The spec is ambiguous as to whether the value is UTC or not, hence the
need to be explicit.
While I agree, that is an issue for POSIX.
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.
For every reason you want PIT, we can already use TAI.
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.
Any difference between the current date and UTC renders everything that
interacts with the real world incorrect.
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.
That's true, but the organizations that pick times scales are not the
IETF. We use standards others manage in that regard, exactly because
we're not special - either time is largely local (in which case it
doesn't matter) or you need to interact with the rest of the world,
which agreed on UTC.
The reason UTC is the standard is because it is what the ITU decided
to use and the broadcasters synchronize everything. That can change.
OK, then let us know when any government picks PIT.
Until then, though, the Internet should not be picking something
different when there are already current standards that are sufficient.
Joe