Date: Fri, 19 Jun 1998 17:23:06 +0100 From: "Clive D.W. Feather" <clive@on-the-train.demon.co.uk> What I did was wrote half the process - convert unnormalized time to a number of TAI seconds since some epoch. Rather than writing the other half and risking inconsistencies, it seemed better to simply express it as requiring the normalized time to produce the same result. The draft C9x spec in effect allows the implementation to consult an oracle to determine part of mkxtime's output, which means the draft actually specifies a relation between mkxtime's input and output. Since it's a relation, and not a function, there's not much point to writing the inverse. It's OK to require that the input members of the normalized time should remain unchanged when passed again to mktime/mkxtime; but it's not OK to also require that mktime return the same time_t value, or that non-input struct members (e.g. members not required by the standard, or tm_ext if that kludge is preserved) preserve their values. You've made me spot one gap in my logic. If you set tm_leapsecs to 0 before normalizing, the time is effectively TAI, while if you set it to _NO_LEAP_SECONDS it is effectively UTC. The output, however, is always UTC (unless there is no leap second database, in which case tm_leapsecs is set to _NO_LEAP_SECONDS). There's no trivial way to convert it to TAI, unless you know of an algorithm. Do we need a _USE_TAI value as well (indicating that the result should be TAI) ? I don't think the current draft's primitives are suited for conversion between UTC and TAI. If it were, then there would have to be an easy way to generate a broken-down TAI time from a time_t value. If it's important to support things like this, the primitives need to be rethought. But I suspect that the vast majority of users don't care about TAI, and that this sort of feature doesn't need to be in the standard. I believe that the <time.h> primitives need rethinking anyway. If we're going to reform mktime, for example, we should separate the original broken-down time from the broken-down time to be added, since that will remove some gotchas with the current approach. E.g. one month after Aug 31 ought to be Sep 30; but mktime yields Oct 1 because it can't distinguish ``add one month to Aug 31'' from ``add one day to Sep 30''. (This problem also resurfaces with leap seconds.) But more important, implementation experience, both on the part of implementers and users, is necessary before the standard is changed. It's unwise to add more <time.h> primitives without significant, public real-world experience.