FW: TAI zone?

[Robert Elz]

    Date:        Wed, 29 Jun 2011 13:16:33 -0400
    From:        "Olson, Arthur David (NIH/NCI) [E]" <olsona at dc37a.nci.nih.gov>
    Message-ID:  <996D816825CFEA469870126E9050D3F001C3BC1EA8 at NIHMLBX11.nih.gov>

One last comment (from me) about the original topic of this discussion
(rather than the posix time_t discussion it devolved into)...

  | From: David Magda [dmagda at ee.ryerson.ca]
  | Sent: Wednesday, June 29, 2011 11:26 AM

  | Is there any reason why a TAI "time zone" ("TZ=TAI; export TZ") is not
  | present for those that want to ignore leap seconds? 

Earlier I said ...

kre at munnari.oz.au said:
  | ps: the only problem with adding a TAI zone, is that it requires a leap
  | second table that's constantly updated ...

but upon further reflection, and after reading Guy's most recent message,
I think that comment of mine was nonsense.

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().

You cannot just "ignore leap seconds" and expect to produce meaningful
results.

Doing this is precisely what the "right/*" set of timezone data does, so if
you have a TAI second counter, that's the way to handle it, and you can
get the result in any timezone that's appropriate, not by attempting to
invent a meaningless TAI timezone.

kre