Hi, all,
Again, this discussion is continuing over in ART at the advice of the IESG.
I'll post followups there.
Joe
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.
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
--