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
Date: Tue, 13 Oct 1998 17:47:19 +0200 From: Antoine Leca <Antoine.Leca@renault.fr> we can classify all the possible implementations in the following order: 1st, those implementations that know both UTC and TAI "perfectly".... 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. (1) and (2) actually form a sort of continuum, not a dichotomy, since no implementation can know UTC-TAI "perfectly" for all future timestamps. In other words, all implementations (even libtai, or Olson in "right" mode) operate with incomplete leap second tables; it's just that some tables are more incomplete than others. A simple way to allow both (1) and (2) is to have an API that makes the leap second table accessible. Once you do this, you can support all the implementation continuum between (1) and (2). 3rd, those implementations that only know about UT [without leap seconds]... 4th, worse, those ... that ... only know "some form of local time".... 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. That sounds reasonable, and an integer-timestamp API can do this, as does the struct xtime API. 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. Sorry, you've lost me. If you want a simple integer timestamp, you don't need 2 functions for each functionality; it suffices to return a single count of subseconds. C9x has 64-bit integers, and 64-bit subsecond timestamps suffice for the vast majority of applications, so it's reasonable to return a single integer instead of returning a struct. Higher-quality implementations can return even longer timestamps (e.g. 128 bits) if there is need for this.
参加者 (2)
-
Antoine Leca -
Paul Eggert