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@xxxxxxx> 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