I believe we should try to advance beyond the points of disagreement exposed by some of us. I think the main point of disagreement is about the format of the basic type to be used for holding time. On one side, Clive Feather proposed an improvement over struct tm. OTOH, all others proposed improvements over time_t. If we followed this later way, I think we can classify all the possible implementations in the following order: 1st, those implementations that know both UTC and TAI "perfectly". I think this is the kind of implementations David has in mind. It is certainly the current case of tz-based up-to-date machines. It will also be the general case of the up-to-date boxes with Internet connection in a near future, IF our plan passes in C9X! 2nd, those implementations where the clock is UTC based and that have some knowledge about leap seconds, but where the famous table is not known to be correct. As Markus highlighted, and fears, this case is in my mind common, and should not be impaired too much; but it is only 2nd class. 3rd, those implementations that only know about UT, without any precision, and that don't know about leap seconds; in fact, it is like many informed people, or like Posix. 4th, worse, those implementations that even do not know about time zones, and that only know "some form of local time". Like Ms-Dos. 5th, if it even exists, those that cannot figure what time is it. I doubt it really exists, but traditionnaly C handles them. My idea is that the API to be proposed should work OK and smoothly with all classes, with priority given to the highest class(es) where there are choices to make. The main point is that everything (except the last class!) ends up as counts of seconds, and sometimes subseconds; but having to manage 2 functions for each functionnality seems too much for me; therefore I prefer something along the lines of struct taia or struct xtime. Not specifying what real kind of time counter is used is fairly frequent in the C standard: it is said to be unspecified. Sometimes, Markus's xtime_conv would then permit to convert this unspecified format to some other its application is aimed at (we have now numerous examples of applications where either TAI, either UTC or decomposed Gregorian are better fitted ;-) ). Can it works? Antoine