Re: FreeBSD handles leapsecond correctly

"Poul-Henning Kamp" <phk_at_phk.freebsd.dk> writes:

>>I'm only annoyed that POSIX pretends leap seconds were non-existant, and
>>even more because I have no satisfactory answer to my question how
>>FreeBSD knows that a file created at 23:59:59.2 is older than a file
>>created at 23:59:60.1 if the timestamp is recycled but rather
>>unsubstantiated assumptions about the amount of research I have done. I
>>don't want to bore readers on mailing lists with epic breadth...
>
> No POSIX compliant system can tell the difference, not even FreeBSD.

Well, some systems appear to be cheating, at the expense of "length of a
second"...

>>Markus Kuhn suggested adding a new interface, or as an alternative
>>solution, smoothing the UTC by slewing the clock ("UTS") for the past
>>1,000 seconds before the insertion or deletion of the leap second.
>
> Yes, that is a total non-starter, now we don't even know how long
> seconds are going to be any more :-(

...as you word it. Some systems seem to actually be doing this, in a
slightly different manner, today. Check Linux's kernel/timer.c (I was
looking at SUSE 10.0, which is based on 2.6.13), if NTP tells Linux
"heya, how 'bout a leap second insertion today", Linux will log a
message at UTC midnight, slew the clock by 500 ppm and compensate over
the next 2,000 seconds, without stepping backwards. You can argue that
Linux's notion of a second is off (because it's actually 1,000.5 ms),
and that the clock is off during these 33'20" - on the other hand, time
of day is monotonic, a "make" process running during the leap second and
its preceding second.

> Computers should use UTC because UTC underlies civil timekeeping.

I don't care the least about civil timekeeping if it breaks builds. The
simple solution would be to block all file creations by non-realtime
processes during that inserted leap second, which causes similar
symptoms to an I/O load spike (or disk retry on read or whatever) that
prevent 23:59:60. Yes, it's ugly. But at least it doesn't break builds.

And tell me one reason why the leap second must be discontinued while
the leap day (Feb 29th) can be carried on. It's the same story,
irregular rollover, inserting one particular unit of time.

> It's the definition of UTC that is the problem, not the choice of it.

Seems like exchanging cause and effect. If it's got a problematic
definition, why choose it?  Of course FreeBSD won't change POSIX and we
don't want to deviate from POSIX 

>>Does POSIX specify a solution to the problem with the ordering of the
>>two files' age I outlined above? Not to my knowledge, so how can it
>>possibly be "correct"?
>
> If there are no more leap seconds, POSIX doesn't have to specify
> how to deal with them.

That one excess "if"...

>>It appears all POSIX machines I look after got the leap second right one
>>way or another[...]
>
> None of them got it right by any strech of the imagination because 
> it is impossible to get it right and be POSIX compliance.

Wow, and you claim FreeBSD handles it correctly.

-- 
Matthias Andree