> However, iIt appears that you are still using "seconds from epoch" for
> internal storage and manipulation, which means there's still some
> fundamental breakage.
>
> If we're going to have a new time/date implementation, I'd like to see one
> that actually deals with leap seconds properly when the OS supports it, i.e.
> has seconds that are always a second in duration.
>

You are not quite right. Yes, it uses "seconds from epoch" for
internal representation, but it  doesn't mean library can't handle
leap seconds. You should just use right timezone. I've added example
with leap second in README. About future dates and leap seconds: tz
database cannot be changed untill program work, so relation time_t <->
year-mon-day-hour-min-sec-tz doesn't change also. When we store time
in persistent store, it converts to year-mon-day-hour-min-sec-tz
presentation, and, if new program will have new tz database, it will
use new correct time_t value. We should only add check if system
support timezones, and automaticaly enable/disable it.
--
Pavel