DOC: explicitly define numpy.datetime64 semantics #20774
Conversation
Explicity state datetime64 semantics: - adoption of proleptic Gregorian Calendar - Astronomical year numbering - 86400 s constant length of day. Add some exmples of shortcomings of the above semnatics with ref. to UTC timescale (missing leap seconds) and UT timescale (variable legth of day). Closes numpyGH-20675
|
|
||
| The computed results, `50491123200` seconds, is obtained as the elapsed | ||
| number of days (`584388`) times `86400` seconds; this is the number of | ||
| seconds of a clock in sync with earth rotation. The exact value in SI |
There was a problem hiding this comment.
I'm confused here, wouldn't a clock in sync with the earths rotation be UTC?
There was a problem hiding this comment.
No, by defnition a clock in sync with earth rotation would be UT1 or, disregarding polar motion, simply UT. It is known that the earth is slowing down its rotation rate, therefore one UT1 second is not a uniform time scale. UTC on the contrary ticks at exactly one SI second rate, and therefore is "uniform". It is the stepping provided by the leap seconds that keeps UTC within 0.9s from UT1 and hence earth rotation.
UTC is a "realized" time scale, so it is not define before its inception (1972 with current rules, 1963 with a different stepping mechanism).
There was a problem hiding this comment.
Maybe note that the value of second will change as the earth's rotation rate changes..
|
This PR is slowly drifting into oblivion... probably because it is considered low priority. Let me try an apology and clarify the motivation. First of all, numpy docs should explicitly state that the proleptic Gregorian calendar with astronomical year numbering is adopted.
Finally the assumption of 86400 second per year is at odds with current civil time usage, because UTC has positive and negative leap seconds. A brief remainder of this fact could be useful and is introduced by this PR. The final part of the PR simply oultines the fact that timestamping distant past event with µs granularity makes little sense, if the adopted timescale is not carefully discussed. In other words we have only an approximate knowledge of the UT timescale in the past (and also in the future, since earth rotation is impredictable with this accuracy) so that the achievable precision (given by the |
|
Sorry for letting this slip by, I did intend to merge it with some clarifications. |
No problem for the delay, this is just a minor correction to the docs. As what regards your request of clarification, I think that we can safely omit the last example, that shows the difference between an uniform SI second time scale (like TAI or TT) and an earth rotation timescale like UT. The discussion of TT vs UT1 is in fact beyond the mere Let me know if you think that I should delete the last example. |
|
I think the difference between uniform seconds and earth rotation seconds is interesting and worth knowing about, it just needs to be clear why fixing a (solar?) day to 86400 seconds results in non-uniform seconds. |
|
Thanks @miccoli . |
Explicity state datetime64 semantics:
Add some exmples of shortcomings of the above semnatics with ref. to
UTC timescale (missing leap seconds) and UT timescale (variable
legth of day).
Closes GH-20675