Time within the machine should be measured relative to its own temporal
frame, but whenever we communicate with another machine we need to
strive to be as close to UTC as possible - warts and all. Anything else
- including and especially smearing - compromises *correct* behavior.
?So you are for sticking with IPv4 as well?
Nothing can ever change because the ITU is in charge...?
?People are only in charge as long as other people let them. ?
The 'obvious' solution is to make programmers, from operating systems all
the way to application programmers, aware that there are different types
of time.
Most programmers should already know that there is a difference between
local time and UTC. We need to extend that a bit.
In particular, we need
- a monotonic 'uptime' that can be used for local timers, etc. independent of
any external time source.
- we need UTC. Civil time is UTC. We have no control over that. For many,
many years we know that leap seconds are a problem, but we are still stuck
with it. For many, many years we also know the daylight saving time is
silly. But we have good solution for the timezone stuff.
- we need a sensible time. There are many ways to define a sensible time,
but TAI is available, so let's use that. For me, sensible time includes
using SI seconds for keeping track of time.
The main thing is that, by and large, this is not a network problem. If a
system uses TAI internally, it can use UTC for NTP, for SMTP, HTTP, etc. The
only thing we may have to do at the network level is improve the availability
of an up-to-date leap second list.
The big thing is, making sure that operating systems offer TAI as a first
class citizen. Making sure that timers are set using MONOTONIC clocks and
making sure that applications that use subsecond precision for time
information internally use TAI and only convert to UTC for interacting
with users.
Unfortunately, there doesn't seem to be an IETF equivalent for operating
systems, so it will be completely random whether anything will happen in
this area or not.