On Tue, 06 Oct 1998 13:55:06 +0100, Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
It would also completely mess up the elegance of my API in that suddenly strfxtime and xtime_make/breakup would have to know from what type of clock this timestamp came:
Note that in my encoding, the two times
1972-01-01 00:00:00 UTC
and
1972-01-01 00:00:00 TAI
(which are 10 s apart) are represented by the same xtime value. An xtime value is just seen as an encoding for a year/month/day/hour/minute/second representation, and any routine that wants to convert these xtime values into broken-down values does not have to knwo whether this is a UTC or TAI (or even a local time) value. With your alternative, this would not work any more, unless you use 86401 seconds per day for both UTC and TAI (which your clause "If T is a TIME_UTC timestamp" does not suggest).
How can strfxtime() determine what clock the xtime value being passed refers to? For the time 1972-01-01 00:00:00 UTC, we have the TIME_UTC value {86400*365*2,0} and the TIME_TAI value {86400*365*2+10,0} (per the definition of TIME_UTC and TIME_TAI in the documetation of the xtime_get() function). These are different, so I fail to see how strfxtime() can avoid having knowledge of which clock the xtime value refers to. When I read the proposal I presumed that only TIME_UTC values should be passed to strfxtime() (whether the result of the appropriate xtime_get() or xtime_conv() call). I now feel that the failure to explictly state that strfxtime()'s xtime argument should be a TIME_UTC value is a bug in the documentation of the strfxtime() function. --Ken Pizzini