The second is broken: Difference between revisions

From PhysWiki
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"


2012-Jun-30 23:59:58.000 2456109.499976852
"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!"
2012-Jun-30 23:59:58.667 2456109.499984568
 
2012-Jun-30 23:59:59.333 2456109.499992284
"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?"
2012-Jul-01 00:00:00.000 2456109.500000000
2012-Jul-01 00:00:00.667 2456109.500007716
2012-Jul-01 00:00:01.333 2456109.500015432
2012-Jul-01 00:00:02.000 2456109.500023148


</blockquote>
</blockquote>

Revision as of 17:55, 27 December 2023

JULY 25, 2022

It’s time to leave the leap second in the past

"While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead."

"At Meta, we’re supporting an industry effort to stop future introductions of leap seconds and . . . we believe it is time to introduce new technologies to replace it."

"At best, such a time jump crashed programs or even corrupted data, due to weird timestamps in the data storage."

"The impact of a negative leap second has never been tested on a large scale; it could have a devastating effect on the software relying on timers or schedulers."

"In any case, every leap second is a major source of pain for people who manage hardware infrastructures."

November 28, 2012

What time scale is 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"

"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?"