ietf
[Top] [All Lists]

Re: Predictable Internet Time

2017-03-29 00:52:40
On 28 Mar 2017, at 19:47, Joe Touch wrote:

On 3/27/2017 11:37 PM, Patrik Fältström wrote:
Joe,

I have read your I-D and like it! Let me start there :-)

What I think is not clear enough is the problem with POSIX, and it should be 
more clear in some place, maybe section 6.1, that POSIX definition which is 
in use in quite a number of systems do not handle leap second very well. Too 
many do believe the time_t definitions include the number of seconds since 
epoch when in reality it does not (as you note in the definitions).

I can make that more clear, but AFAICT POSIX time is *defined* as seconds 
since the Unix epoch *not counting* leap seconds at all.

Well, one of the problems is that the specification of POSIX time is a bit 
unclear.

One could even question whether it is Continuous as two seconds will have 
the same number since epoch around the addition of a leap second

It is Continuous by definition.

When UTC adds a leap second, nothing different happens to POSIX time.

No, that is not correct if you look at the day when the leap second is added.

POSIX is number of (days * 86400) plus seconds inside the current day. This 
implies if there is a day with a leap second there will be 86401 seconds which 
also will be the first second the following day.

There are some people that have suggested a change, for example 
<http://www.cl.cam.ac.uk/~mgk25/time/c/> but I have not seen any movement. 
Maybe you know more than me on this?

AFAICT, that's just attempting to redefine the <time.c> interface as 
returning UTC rather than POSIX time.

The UNIX time_t struct do deliver UTC, including leap seconds, but the number 
of seconds from epoch is wrong regarding leap seconds. Includes one leap second 
within the day of the leap second being added and without leap seconds 
otherwise.

Which works *IF* your machine has access to updated leap-second information, 
e.g., via NTP.

Correct, if one have access to leap seconds, one could adjust the number of 
seconds and that could happen already today as POSIX definition is a bit 
unclear on this. But people have not implemented it. So instead for example 
Google smear the leap second over the day so that there is not bump in the 
road, and they run NTP servers that do give back this smeared time that differs 
from UTC.

All just because a. unclear information from POSIX and b. bad implementations 
in *ux.

   paf

Attachment: signature.asc
Description: OpenPGP digital signature