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.
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.
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" ?
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
> --
--
---
tte@xxxxxxxxx