The second is broken: Difference between revisions
No edit summary |
No edit summary |
||
Line 26: | Line 26: | ||
"I'm confused by the ust of the term "UT" in the description of time scales used by the JPL HORIZONS system." | "I'm confused by the ust of the term "UT" in the description of time scales used by the JPL HORIZONS system." | ||
"My understanding is that UTC has leap seconds, so that there should be an extra second at the end of a day on which a leap second was added, but the intervals reported by HORIZONS lacks these, and look more like UT1 | "My understanding is that UTC has leap seconds, so that there should be an extra second at the end of a day on which a leap second was added, but the intervals reported by HORIZONS lacks these, and look more like UT1" | ||
"Even more confusingly, the data reported do in fact behave as if the times are UTC. For example the reported azimuth of Pluto at Greenwich for the times above changes by 0.0028° for each of the intervals but the third, where it changes by 0.0069°, a factor of 2.5 times the change in each of the other intervals, which is exactly what would be expected ((1 + 2/3)/(2/3)) if there were an extra second between 2012-Jun-30 23:59:59.333 and 2012-Jul-01 00:00:00.000. This, despite the fact that the difference in JD over that interval is the same as each of the other intervals, meaning that one can't expect differences between JD that span any leap seconds to line up with changes in data!" | |||
"If the times and data are UTC, how can the differences between JD be uniform? If they're UT1 how can the data "jump" at the leap second?" | |||
</blockquote> | </blockquote> |
Revision as of 17:55, 27 December 2023
JULY 25, 2022 |
It’s time to leave the leap second in the past
|
November 28, 2012 |
What time scale is used by the jpl horizons system?
|