Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instant.from-posix has faulty pre-1972 leap second knowledge #4566

Open
p6rt opened this issue Sep 20, 2015 · 1 comment
Open

Instant.from-posix has faulty pre-1972 leap second knowledge #4566

p6rt opened this issue Sep 20, 2015 · 1 comment
Labels
Bug

Comments

@p6rt
Copy link

@p6rt p6rt commented Sep 20, 2015

Migrated from rt.perl.org#126121 (status was 'new')

Searchable as RT126121$

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Sep 20, 2015

From zefram@fysh.org

Reusing the function I explained in [perl #​126119], let's look at 1970​:

$ ./perl6 -e 'sub leaps-between ($a, $b) { (Instant.from-posix($b) - Instant.from-posix($a)) - ($b - $a) }; say leaps-between(0, 31536000)'
0

No leaps. Is that right? Not really.

In 1970 there were no leap seconds of the modern type. But UTC was
not moving in lockstep with TAI, the way it does in a modern leapless
year such as 2014. In fact, for the whole of 1970, each UTC second
lasted exactly 1.00000003 TAI seconds. This is in the so-called "rubber
seconds" era of UTC. So the 31536000 UTC seconds of 1970 lasted exactly
31536000.94608 TAI seconds, and so the leaps-between function ought to
reflect that by returning a value of exactly 0.94608 s for this interval.

Similar considerations apply throughout the period from 1961-01-01 to
1972-01-01. In this era, the UTC second had a length slightly offset from
that of the TAI second, the offset being occasionally changed at the start
of a year. There were also instantaneous leaps, of almost the modern
form, always at the end of a month and by some fraction of a second.
See <http://maia.usno.navy.mil/ser7/tai-utc.dat> for defining expressions.

However, this analysis depends on strictly interpreting POSIX time_t
values, for the purposes of Instant.from-posix() as being based on UTC.
This is what the POSIX standard says, but it doesn't match historical
Unix practice of the era. If the input to Instant.from-posix() is to be
interpreted more loosely, then tai-utc.dat is not directly applicable.
But that doesn't get you off the hook​: the loose interpretation is still
that time_t values are based on some form of UT, and so it still needs
to show leaps relative to TAI. The difference is that you have greater
freedom in choosing the details of the leaps.

-zefram

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.