Ken Pizzini wrote on 1998-10-07 09:12 UTC:
Markus Kuhn <Markus.Kuhn@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/>