On 2014-01-18 12:02, Joseph Gwinn wrote: >> [POSIX time] ... >> It's defined as a transformation of a broken-down UTC timestamp, not >> (despite its name) as a count of seconds since some instant. > > No. If your poke around into how time is used, you will discover that > what is stored in the cound of seconds since the Epoch. Broken-down > time is used only when there is a human to be humored.
A count of "non-leap seconds" since the Epoch. That is a crucial difference, and it's (IMHO) the root cause of many leap second problems. time_t presents itself as "elapsed time", and is frequently used that way, but it is not elapsed time in the usual meaning of the term (i.e. number of elapsed SI seconds). It's frustrating, because POSIX comes really close to providing both of the aspects of time (elapsed duration and civil time) that applications require. It wisely provides a human readable time structure (struct tm), and functions to convert this to and from time_t, but then requires time_t to satisfy a simple formula so that the conversion between struct tm and time_t is fixed. If it just dropped that formula and required use of library functions to convert time_t to/from struct tm then it would at least be possible to implement time_t as a true count of elapsed seconds on a POSIX compliant system. Alas, there are difficulties with this too -- leap seconds are unpredictable, and interchange of file timestamps between POSIX systems becomes harder. Maybe the way forward would be to introduce a new "elapsedtime_t" type that really does count seconds since the Epoch (to be used in any applications that require duration) and to deprecate arithmetic on time_t values (which is problematic around leap seconds). Eric _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
