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