| |||||||||||||
The leap second bugThe leap second bugPosted Jul 2, 2012 19:58 UTC (Mon) by chip (subscriber, #8258)In reply to: The leap second bug by slashdot Parent article: The leap second bug
POSIX decided to enshrine the convention that when time() % 60 == 0, then now is the top of a minute. I must say when I first heard them do that, I was VERY pleased, because ANSI is so wishy-washy about times.
Too late to reconsider it, IMO.
(Log in to post comments)
The leap second bug Posted Jul 2, 2012 23:33 UTC (Mon) by slashdot (guest, #22014) [Link]
Are applications relying on that?
The thing is that you can only get UTC h:mm:ss and local timezone seconds using modulus on time_t, due to half-hour-offset timezones, DST and irregular month lengths.
Now, you generally either want to display UTC date+time or local h:mm:ss at least, neither of which you can do without calling library functions, so maybe not much or anything will break?
I'm not sure I'd risk it though, and not adding leap seconds ever again to UTC seems a much better solution.
The leap second bug Posted Jul 4, 2012 6:13 UTC (Wed) by butlerm (subscriber, #13312) [Link]
>POSIX decided to enshrine the convention that when time() % 60 == 0, then now is the top of a minute.
That is a perfectly adequate (if not ideal) convention for use in generating representations of civil time. Month, day, year and so on. The problem comes where programs (and kernels) are designed around the preposterous presumption that POSIX time has any reliable relationship to real time.
That might work reasonably well when your timeouts are measured in a cardinal number of seconds greater than two, but experience clearly demonstrates that using POSIX time (or UTC) for anything requiring sub-second accuracy is foolish in the extreme. It amounts to designing a system to fail with a high probability every three or four years.
|
|||||||||||||