Proposal for new ISO C 9x time API

[Markus Kuhn]

Ken Pizzini wrote on 1998-10-07 09:12 UTC:
> Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk> wrote:
> >  If you have a TAI timestamp and what to
> > print it as a TAI timestamp, then you just pass to strfxtime the TAI
> > timestamp and specify NULL as the time zone. NULL means that the output
> > shall be a "UTC time", but since the relationship between xtime and
> > broken-down time is identical for both TAI and UTC, you will get the
> > correct TAI output as well with NULL. Therefore, strfxtime can also be
> > passed TAI timestamps with a NULL timezone_t in order to print correct
> > TAI timestamps and strftime() does not even have to know about that this
> > is a TAI timestamp.
> 
> I'm sorry, I still fail to follow this.  1972-01-01 00:00:00 UTC
> has a TIME_UTC xtime of {86400*365*2,0} and TIME_TAI has an xtime
> of {8600*365*2+10,0}, and TIME_UTC counts non-leapseconds while TIME_TAI
> counts all seconds, including leapseconds.  So the xtime values for the
> same instant in time on these two clocks will always differ by (TAI-UTC)
> seconds, and values on these two clocks will differ for the same
> broken-down time representation.

Exactly. As they are supposed to be! Look:

If we place a UTC and a TAI clock next to each other, we see the
following at this point in time:

  1972-01-01 00:00:00 UTC    =    1972-01-01 00:00:10 TAI

If you feed {86400*365*2,0} (the UTC value) into strfxtime you get
1972-01-01 00:00:00 as output (the correct UTC clock display) and if you
feed {8600*365*2+10,0} (the corresponding TAI value at the same time)
into it, you get 1972-01-01 00:00:10 as output (the correct TAI clock
display at the same time). So everything works out exactly right. (With
(timezone_t *) NULL in each case.) Wonderful, isn't it?

May be you just didn't understand that a TAI clock does indeed show a
different time than a UTC clock?

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>