[tz] What's "right"?
gharris at sonic.net
Sat Nov 14 00:43:14 UTC 2020
On Nov 13, 2020, at 3:51 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 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.
So what documents indicate how UTC was implemented prior to 1972-01-01 00:00:00 UTC? And what documents discuss the changeover to "new" UTC (decision made in 1970 to start "new UTC' in 1972?)?
And, for anybody who cares in that much detail about the definition of the Epoch, should 1970-01-01 00:00:00 UTC be interpreted as *literally* being 1970-01-01 00:00:00 UTC, or as 1970-01-01 00:00:00 "new UTC extended backwards", i.e. "TAI, and new UTC extended backwards, were 10 seconds apart from the beginning of TAI all the way up to 1972-06-30 23:59:59, and then new UTC started getting leap seconded"?
More information about the tz