On 19 Apr 2017, at 1:21, 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" ? I want as potential fixes which I think are doable: - an updated POSIX definition where the variable which holds the number of seconds since the epoch when converting back and forth to date actually will hold the number of seconds since the epoch. - a slot in the NTP protocol not used today include the number of leap seconds so people get to know that. FWIW I am a person that is against smear. I think a clock must be able to give the correct time and that timestamps should be correct. Either in seconds (and fractions of seconds) since the epoch or in correct date and time UTC. Both are increasing all the time. And because of that smear should not have to happen. That said, I am not against a BCP explaining the issues due to for example the broken POSIX specification (which makes it hard to "do the right thing" in software). Patrik
Attachment:
signature.asc
Description: OpenPGP digital signature