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.