Antoine.Leca at renault.fr
Tue Oct 13 15:47:19 UTC 1998
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?
More information about the tz