[Top] [All Lists]

Re: Predictable Internet Time

2017-04-19 00:18:51
On 19 Apr 2017, at 1:21, Toerless Eckert wrote:


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 


Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>