Wie gehen Physiker und Astronomen mit Schaltsekunden um?

Ich bin verwirrt von den vielen widersprüchlichen Beschreibungen, die ich darüber sehe, wie UTC-Schaltsekunden berücksichtigt werden. Ich verstehe, dass es in der gängigen Praxis verschiedene Möglichkeiten gibt , mit ihnen umzugehen, und ich habe eine Vielzahl formaler Definitionen gesehen. Aber es scheint, dass sie in der wissenschaftlichen Praxis einfach weggelassen werden: Es gibt keinen UTC Julian Day (das ist kein JD(UTC)-Wert), der Zeiten während einer Schaltsekunde entspricht, und Dinge wie Ephemeriden werden im Allgemeinen nicht für Schaltsekunden gemeldet . Natürlich gibt es Ereignisse, die während Schaltsekunden stattfinden, aber wenn man sich auf den Zeitpunkt beziehen möchte, zu dem sie auftreten, verwendet man ein anderes Zeitnahmesystem (z. B. UT1 oder TT).

Ist das richtig? Es ist absolut sinnvoll, um die Mehrdeutigkeiten zu berücksichtigen, die Schaltsekunden einführen, und es entspricht tatsächlich der Art und Weise, wie einige Systeme (z. B. POSIX ) sie implementieren; aber es stimmt nicht ganz mit den Definitionen überein, die ich gesehen habe.

Dies entspräche der Art und Weise, wie Kim Stanley Robinson mit dem „Zeitsprung“ des Mars umgeht : Uhren werden um 24 Erdenstunden angehalten und 39 Minuten und 40 Sekunden später wieder gestartet.
Ich habe darüber nachgedacht und bin zu dem Schluss gekommen, dass die Schaltsekundensprünge in den Ephemeriden nicht berücksichtigt werden. Sie sind nur da, um unsere UTC-Uhren mit der Erdrotation, dh UT1, synchron zu halten.
@JoeH: Aber zum Beispiel ändert sich der Azimut-JPL-Bericht für Pluto in Greenwich zwischen dem 30. Juni 2012, 23:59:59,333 UTC und dem 01. Juli 2012, 00:00:00,000 UTC um das 2,5-fache dessen, was er ändert jedes andere "1"-Sekunden-Intervall in der Nähe: 0,0069° gegenüber 0,0028°, was genau das ist, was zu erwarten wäre ((1 + 2/3)/(2/3)), wenn es dort eine zusätzliche Sekunde gäbe.
Da bin ich ratlos. Verzeihung.

Antworten (2)

Wie Sie wissen, verwenden Astronomen nicht UT für Berechnungen, sondern Julian Days (JDs). Nachdem die Berechnung abgeschlossen ist, wird das resultierende JD zurück in UT, UTC oder die gewünschte Zeitzone für die Öffentlichkeitsarbeit konvertiert.

Schaltsekunden können aus historischen Daten (z. B. NASA http://eclipse.gsfc.nasa.gov/SEhelp/deltat2004.html oder US Navy ftp://maia.usno.navy.mil/ser7/deltat.data ) oder entnommen werden wenn diese nicht verfügbar sind, können sie berechnet werden http://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html . Sie werden als ΔT bezeichnet.

ΔT wird dann zu JD addiert und diese Zeit wird JDE (Julian Ephemeris Day) genannt. Oder anders ausgedrückt: JD wird aus UT berechnet, JDE jedoch aus dynamischer Zeit (TD = UT + ΔT).

Seit den frühen 1990er Jahren haben einige Veröffentlichungen wie Minor Planet Circulars (http://www.minorplanetcenter.net/iau/services/MPCServices.html) JDE in JDT umbenannt, wobei T die Beziehung zur Terrestrial Dynamical Time bedeutet.

Die Frage bezieht sich auf die Konvention, die in diesem letzten Schritt beim "Rückkonvertieren" in UTC verwendet wird. Es sieht so aus, als würde (a) JD(UTC) sich nicht auf Schaltsekunden erstrecken und dass – möglicherweise als Folge von (a) – Daten nicht konventionell für Schaltsekunden gemeldet werden. Was die Frage inspiriert hat, ist ein Blick auf die JPL-Ephemeridendaten um eine Schaltsekunde herum, die in UTC gemeldet werden: Sie lassen die Schaltsekunde weg und überspringen die Schaltsekunde beim Zählen von JD (UTC).
@Hidden Für jede definierte Zeitskala gibt es eine entsprechende julianische Tageszahl, also gibt es tatsächlich eine julianische UTC-Tageszahl. Die Quantität Δ T steht nicht in direktem Zusammenhang mit Schaltsekunden. Schaltsekunden werden eingeführt, um die Diskrepanz zwischen UTC und UT1 auf weniger als eine Sekunde zu bringen. @raxa Ich habe dieses Problem nicht vergessen. Mein Semester neigt sich dem Ende zu und ich werde nach den Prüfungen darauf zurückkommen.
@raxacoricofallapatorius Hmm, Schaltsekunden werden hinzugefügt, wenn es sich ansammelt, und dann nur an zwei Daten in einem Jahr, dem 30. Juni und dem 31. Dezember. Es ist programmatisch trivial, dies dem Algorithmus von JD zu UT hinzuzufügen. Wenn Sie daran interessiert sind, wie JPL-Daten erstellt werden, warum senden Sie ihnen nicht eine E-Mail?
@JoeH Was meinst du damit, dass ΔT nicht direkt mit Schaltsekunden zusammenhängt? Wie auch immer ... ich freue mich auf Ihre Antwort ... Ich glaube, physical.stackexchange.com ist eine großartige Ressource zum Lernen und jede konstruktive Antwort ist mehr als willkommen!
Ich verstehe die verschiedenen Beziehungen zwischen Zeitskalen (TT, TAI, UTC, UT1 usw.) und die Rolle von Δ T und Schaltsekunden in diesen Beziehungen. Und ich habe JPL gefragt. Aber es ist ziemlich klar, was sie tun: (a) für Daten, die zu UTC-Zeiten präsentiert werden, melden sie keine Daten für eine Schaltsekunde und (b) sie zählen JD(UTC), als ob es keine Schaltsekunde gäbe. Die Frage hier ist: Ist das – insbesondere das vollständige Weglassen von Schaltsekunden aus der JD(UTC)-Buchhaltung – eine Konvention (was Sinn macht) oder vielleicht sogar eine formale Definition oder einfach etwas Eigenartiges, was sie tun.
Was ich meine ist, dass ΔT UT1 auf eine ungefähr gleichförmig fließende Zeitskala, Dynamische Zeit, bezieht, während UTC und UT1 durch Schaltsekunden zusammenhängen. Schaltsekunden sind nur da, um UT1 und UTC innerhalb von 0,9 Sekunden voneinander zu halten.

Sie haben völlig Recht: Bei der Zuordnung von JD-Realzahlen zu UTC-Kalenderdaten ist es einfach unmöglich, einen Moment während der Schaltsekunde zu benennen – während eine analoge Wiedergabe einer UTC-Zeit „23:59:60,25“ sagen kann, wird der JD liefern kein Name für irgendeinen Moment dieser ganzen Sekunde.

Dies ist ersichtlich, wenn Sie das Standardsystem von JPL HORIZONS besuchen:

http://ssd.jpl.nasa.gov/horizons.cgi

Wenn Sie eine Startzeit von 2012-6-30 23:59:58und eine Endzeit von 2012-7-1 0:00:02eingeben und nach einer Schrittgröße von 5 „gleichen Intervallen“ fragen, haben Sie fairerweise erwartet, dass Sie die 5 Sekunden zwischen diesen beiden Zeiten als Ihre fünf gleichen Intervalle erhalten. Aber wenn Sie in Ihren Tabelleneinstellungen „Delta-T“ und „Datum-Zeit-Format: Beides“ auswählen, werden Sie stattdessen sehen, dass HORIZONS die Schaltsekunde vergisst, wenn es den gewünschten Zeitraum in 5 Teile teilt:

$$SOE
     2012-Jun-30 23:59:58.000 2456109.499976852 *m     66.184122
     2012-Jun-30 23:59:58.800 2456109.499986111 *m     66.184122
     2012-Jun-30 23:59:59.600 2456109.499995370 *m     66.184122
     2012-Jul-01 00:00:00.400 2456109.500004630 *m     67.184122
     2012-Jul-01 00:00:01.200 2456109.500013889 *m     67.184122
     2012-Jul-01 00:00:02.000 2456109.500023148 *m     67.184122
    $$EOE

Hier tritt eindeutig eine Schaltsekunde auf – Sie können sehen, wie der Delta-T-Wert um 1 Sekunde springt! Aber der JD-Anteil hat eindeutig keinen „Raum“, um die Schaltsekunde zu benennen, und HORIZONS auch nicht: Sie wird in die nachgelagerten Berechnungen einbezogen, kann aber nicht als Eingabe für das System benannt werden.