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
signature.asc
Description: OpenPGP digital signature