Proposal for new ISO C 9x time API

[Ken Pizzini]

On Tue, 06 Oct 1998 13:55:06 +0100,
Markus Kuhn <Markus.Kuhn at 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