# [tz] What's "right"?

Paul Eggert eggert at cs.ucla.edu
Fri Nov 13 23:51:49 UTC 2020

```On 11/13/20 2:51 PM, Guy Harris wrote:
> Do not think of the input to gmtime() and localtime(), or the output of mktime(), as being "UTC" or as being "TAI - 10", think of it as being either "a count of seconds, other than leap seconds, since the Epoch" or "a count of seconds, including leap seconds, since the Epoch", the Epoch being the same in both cases.

This all sounds like good advice.

The tricky part that I can see here, is that if you're using the "right"
approach (where time_t is theoretically supposed to count TAI seconds),
then timestamps before 1972 are all treated as if TAI−UTC equaled 10,
which is not correct (for a reasonable definition of "correct"). For
example, when time_t is 0 the "right" approach as implemented will
report 1970-01-01 00:00:00.000000, even though a clock that consistently
ticked TAI seconds should report a slightly different time.

For the period from 1968-02-01 until 1972-01-01 I think the equation is:

TAI−UTC = 4.2131700 s + (MJD − 39126) × 0.002592 s

where JD is the Julian Date and MJD = JD − 2400000.5. The MJD for
1970-01-01 is 40587, which means that TAI−UTC was 8.000082 (not 10) at
the POSIX epoch, which means for time_t 0 the "right" approach arguably
should report 1970-01-01 00:00:01.999918.

That's not the way "right" is implemented, of course. In "right", time_t
values count TAI seconds starting in 1972, and UTC seconds before 1972.
(So the name "right" is a bit of a misnomer....)

I don't know of any operating system that supports TAI seconds
"correctly" back to the dawn of TAI (however one wants to define when
that dawn occurred). It would hardly be worth the trouble, I'd think. It
may well make sense, though, for some astronomical applications to do
the conversion "correctly", when interpreting historical astronomical data.
```