Re: Predictable Internet Time

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]> 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
>