Re: [art] Predictable Internet Time

[Joe Touch <[e-mail]>]

Continuing this in ART, as advised by the IESG:


On 4/18/2017 4:21 PM, Toerless Eckert wrote:
> Nice!
>
> Why not start to tackle the problem pragmatically before asking for standards
> when its clearly a political issue.
>
> a) RFC describing the problems developers and system deployments can face
>   because of leap seconds.
That's what draft-touch-time attempts to do.

> b) And best current practices to get around those issues. Eg: Expect clock
>   smear on Jan 1 == reduced accuracy of ~1. Unless OS or other trusted
>   info source gives explicit indication: NO leap, no smear.

BCP is to use UTC and track leap seconds if you can, or be clear when
that's not possible and your clock (basically) approximates TAI (i.e.,
UTC without leap seconds, such as when not connected to a network).

Nobody should "expect" clock smear - clock smear is just deliberately
inaccurate time.

> c) And finally a description of the worst open issues when b) is applied.
>    Anything worse than labels on products "reduced functionality on Jan 1
>    after a leap second" ?

The IETF doesn't have standards compliance so we can't dictate labels,
so I'm not sure why this is useful to consider.

Joe

>
> Cheers
>     Toerless
>
> On Tue, Apr 18, 2017 at 05:20:06PM -0500, Nico Williams wrote:
>> On Tue, Jan 03, 2017 at 05:34:11PM -0500, Phillip Hallam-Baker wrote:
>>> As I said, I want 30-100 years lead time so I can bake the schedule into
>>> devices and remove a trust dependency.
>> 30 years' lead time for leap seconds?  Can't be done.
>>
>> Leap seconds depend on events such as earthquakes.
>>
>> You can estimate their frequency, but you can't estimate when they'll be
>> inserted.
>>
>> Nico
>> --