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@cantrip.org http://www.cantrip.org/