the ``need'' for POSIX times
D. J. Bernstein
djb at cr.yp.to
Sat Oct 10 00:03:37 UTC 1998
Markus observes that, thanks to leap seconds, we don't know how many TAI
seconds there will be before (say) 2100-01-01 00:00:00 UTC. If you ask
libtai now, its guess will be a minute away from the truth.
What Markus doesn't realize is that POSIX times suffer the same problem.
Thanks to future changes in the calendar, we don't know how many
non-leap seconds there will be before (say) 9999-01-01 00:00:00 UTC.
If you ask Markus's vaporware library, its guess will be wrong by one or
Markus's error here is an order of magnitude worse than the leap-second
error. Shall I review his examples of ``risks'' in this light?
> My TIME_UTC (and also POSIX) provides this reliable relationship between
> the easy to process integer struct value and the full broken-down time.
False. Markus's ``reliable relationship'' will fail as soon as the
Gregorian calendar expires. The POSIX rules break down even sooner.
1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html
More information about the tz