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 more _days_! 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. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html