TAI zone?

[Guy Harris]

On Jun 30, 2011, at 5:31 PM, Random832 wrote:

> On 6/30/2011 2:27 AM, Robert Elz wrote:
>> As best I understand it, TAI is just a count of seconds from its offset,
>> and has no concept of years, months, or days, just seconds
> 
> I've never heard this before. Everywhere i've seen it described it's "34 seconds ahead of UTC" - and UTC has all those. which implies at 00:29:11 UTC it's 00:29:45 TAI [of the same day, except of course for those 34 seconds between the two times' 00:00:00]

One could convert a TAI value, represented as "seconds since the TAI epoch", and:

	divide it by 86400, the number of atomic seconds in an "atomic day", and treat the quotient as the number of days;

	divide the remainder by 3600, and treat the quotient as the number of hours;

	divide the remainder by 60, and treat the quotient as the number of minutes;

	treat the remainder as the number of seconds;

and get a days/hours/minutes/seconds value.

If you then take a UTC value that does not correspond to a leap second, represented as day/hour/minute/second, and subtract the two day/hour/minute/second values, you will get the difference between TAI and UTC at that point.

If you were to convert the UTC day/hour/minute/second value back to a single number as {day}*86400 + {hour}*3600 + {minute}*60 + {second}, you could compute the difference by subtracting the TAI value as "seconds since the TAI epoch" and the UTC value.  The result of said conversion, however, would *not* assign a unique seconds value to every instant in time - the value assigned to a leap second would be the same as the value assigned to an instant after that leap second, which means, of course, that you *CANNOT* take the seconds value in question and, from it, show the value of UTC as day/hour/minute/second, so if you want to be able to display UTC time labels, you *CANNOT* use the seconds value in question (as adjusted for the difference in epochs between TAI and UNIX time) as a time_t.