xtime/libtai/"right"

[Nathan Myers]

> But as noted by Bradley and David before, this is not a problem when
> you are only talking about inode times.

Since when are we only talking about inode times?  Part of the problem 
with tm/time_t is that it works ok for inode times but not for other 
equally-important uses.

The problem with the mktime model is that conversions between civil
time and timestamps can result in 2, 1, or <1 valid conversions, and
neither the user (before the conversion) nor the library is equipped
to favor one result over another, or deal properly with nonexistent
times.  mktime offers no interface for the algorithm to report what 
it finds, so it must falsify its results.  After a conversion, if 
all the results are exposed the client has the information necessary
to make an informed choice.

I hope that any interface offered to improve on mktime will expose the 
information needed to write reliable code.  If it is also "nice" for 
the common ranges where there actually is a one-to-one mapping, that's 
a bonus.

Nathan Myers
ncm at cantrip.org  http://www.cantrip.org/