Hi, Patrik,
On 3/28/2017 10:52 PM, Patrik Fältström wrote:
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.
POSIX asserts that a "day" = 86400 * "seconds" but defines neither day
nor second.
It definitely says it does not include leap seconds, so there cannot be
"plus seconds inside the current day" - doing that assumes that POSIX
days are correlated to UTC days, but that's never stated.
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.
A UTC day with a leap second clearly has to use a different definition
of either 'second' or 'day' than POSIX, which requires that every day
has exactly 86400 seconds.
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.
time_t in POSIX is supposed to return a signed integer of the number of
seconds since the Unix epoch.
any more complicated structure is an attempt by a system to convert its
internal time to UTC, which requires knowing about leap seconds as well
as knowing the relation of the local internal "second" vs the SI version.
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.
IMO, it's very clear that leap adjustments are not part of POSIX time.
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.
They're not using POSIX time then; they're using an internal
approximation of UTC to provide time to NTP.
Joe