TAI zone?

[Guy Harris]

On Jun 29, 2011, at 11:27 PM, Robert Elz wrote:

> And further, the initial request is also pretty meaningless, TAI is not
> (unlike UTC) a timezone, so TZ=TAI makes precisely no sense at all.
> 
> 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, and so attempting
> to use the localtime() set of functions on TAI data makes precisely no
> sense.
> 
> The only thing (aside from using them to measure time differences, etc,
> at which task they work very well) that can be done with TAI in the area
> of absolute times is to determine the correct number of leap seconds to add,
> add them, producing the equivalent UTC time, and then use that with localtime().

There's "time" as a measure as the progress, of, well, *time*.  "How many {fillintheblanko}seconds did this operation take"?  Ultimately, that's the camp to which TAI belongs.

And then there's "time" as in "what label do the dominant ape species on a ball of iron and rock with a layer of mud on top use to identify certain instants of time, based on the rotational and orbital properties of said ball?"  Ultimately, that's the camp to which UTC belongs.

The former is relatively simple, courtesy of cesium-133.

The latter is more complicated, given that the orbit and rotational speed of the ball in question weren't set up with reference to the energy level difference between the two hyperfine levels of the ground state of the cesium-133 atom, and that both change over time.

In the best of all possible worlds, time() would deal with the former, and localtime()/gmtime()/mktime() would deal with mapping the former to the latter.