Umm, my proposal was to ignore the opinion of the ITU in this matter as in
everything else.
They can define UTC how they like. I want something that works robustly and
predictably with no requirements to update tables of leap seconds.
And by robustly, I certainly do not mean people have to test corner cases
that will occur one time in 50 million.
On Tue, Jan 3, 2017 at 1:11 AM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 1/1/2017 11:24 AM, Phillip Hallam-Baker wrote:
To have a complete solution, the way forward would be to require systems
using PIT to use the 'time smear' approach that has been pioneered by
Akamai and is now used by Amazon, Google, etc. albeit in slightly different
and non standard ways.
Using time smearing, a program will never emit the time value 12:59:60 as
demanded by the standard. Instead the leap second is added to the machine
gradually over the course of 20 or 24 hours. This avoids the need to emit a
time value that could cause a system to fail at the cost of a modest
difference between the purported and actual value.
Smearing leads to differing interpretations of elapsed time for two
reasons:
1) smearing isn't unambiguously specified
2) smearing doesn't match the clock standards set by the ITU (who defines
UTC)
A "complete" solution would have several properties:
- it would always indicate the correct UTC time
- it would calculate time differences accurately
There's no clear reason why that solution can't be split into parts, e.g.,
using Unix time to calculate time differences and a (complex) converter to
deal with UTC leap seconds.
Joe