Vraag:
Time standard for IERS Bulletin A
David Hammen
2019-03-15 18:55:13 UTC
view on stackexchange narkive permalink

IERS Bulletin A en Bulletin B bevatten parameters voor de oriëntatie van de aarde. Deze omvatten het tijdsverschil tussen UT1 en UTC en pole position. De waarden voor deze parameters worden eenmaal per dag vermeld, gecodeerd door "MJD" (Modified Julian Date).

De documentatie zegt niet naar welke tijdschaal deze MJD-waarden verwijzen. Zonder kwalificatie wordt MJD meestal gezien als een soort van universele tijd. Als dat het geval is, welke smaak van universele tijd is het dan: UTC, UT1 of een andere smaak? Als dat niet het geval is, wat is het dan?

Ik gebruik de gegevens op een interpolatieve manier (Lagrange-interpolatie) om de aardoriëntatieparameters op willekeurige tijdstippen te schatten, dus ik heb niet de juiste tijdstandaard leidt tot kleine fouten in de geïnterpoleerde waarden.

Twee antwoorden:
Camilo Rada
2019-03-16 00:08:53 UTC
view on stackexchange narkive permalink

Kort antwoord: UT1

Lang antwoord:

De Juliaanse dag (JD) is slechts een consistent aantal dagen sinds het begin van de Juliaanse periode , dat is 12 januari 4713 v.Chr. Omdat de cijfers vaak groot zijn (vandaag is het dag 2.458.557.5), werd in de jaren 80 en ingegeven door computergeheugenbeperkingen de gereduceerde JD gemaakt die slechts $ JD-2400000 $ span is >. Om vervolgens de ergernis weg te nemen dat de Juliaanse dag om 12.00 uur in plaats van middernacht begint, is de Modified JD (MDJ) gemaakt, die slechts $ JD-2400000.5 $ is.

Per definitie is de MJD nul op de middag van de zon op de 0 ° meridiaan. Daarom is het geen reguliere tijdsmaat, het is gekoppeld aan de rotatie van de aarde en versnelt of vertraagt ​​afhankelijk van de minieme variaties van de rotatiesnelheid van de aarde.

Je kunt in principe elke zonnetijd gebruiken, inclusief alle smaken van UT-tijd, om definieer je MJD, maar de meest nauwkeurige is UT1.

Maar UT1 is ook geen normale tijdmeting en wordt ook beïnvloed door variaties in de rotatiesnelheid van de aarde. De enige echt reguliere tijdstandaard die u noemt, is UTC, die is gebaseerd op atoomklokken. Omdat het regelmatig is, drijft de zonnemiddag van UTC af en gebeurt niet om 12.00 uur UTC, daarom worden schrikkelseconden toegevoegd om UTC redelijk dicht bij de zonnetijd te houden. Maar er wordt een record van schrikkelseconden bijgehouden, zodat u UTC kunt gebruiken om nauwkeurig tijdsintervallen te meten, onafhankelijk van de variaties in de rotatie van de aarde.

In die zin zijn UT1 en UTC niet twee smaken van hetzelfde als u suggereert , meten ze eigenlijk twee totaal verschillende dingen. De eerste meet de rotatie van de aarde en de tweede meet de tijd. Om dezelfde reden kan of mag MJD niet echt naar UTC worden gerefereerd (anders zou het niet nul zijn op de middag van de zon).

Dit gezegd hebbende, geeft de MJD in die bulletins precies dezelfde informatie weer als de datum. Dus "2019 1 2", wat 2 januari 2019 betekent, brengt exact dezelfde informatie over als MDJ 58485, het is gewoon een meer machinevriendelijke manier om naar een specifieke dag te verwijzen. En het elimineert ook de noodzaak om rekening te houden met ontbrekende kalenderdagen als u met datums werkt die relatief ver in het verleden liggen.

Als u nu wilt weten hoeveel tijd er is verstreken tussen twee items in de tabel, heeft u dit nodig om te weten hoe ze elke versie van de zonnetijd die ze gebruiken (UT1 in dit geval) kunnen transformeren naar een reguliere tijdreferentie zoals UTC of TAI. Daarom is de waarde "UT1-UTC" opgenomen. In elk geval moet u bij het uitvoeren van een dergelijke berekening rekening houden met eventuele schrikkelseconden die aan UTC worden toegevoegd tussen de tijd van de twee vermeldingen.

Is dat logisch?

Re * Is dat logisch? * Ja, het is logisch, behalve één ding, namelijk dat schrikkelseconden altijd plaatsvinden op de datum waarop schrikkelseconden worden geïnjecteerd in plaats van de dag erna als UT1 werd gebruikt voor MJD. UT1-UTC springt bijvoorbeeld van -0,557 seconden op 30/06/30 naar +0,443 seconden op 31/07/31, van -0,408 seconden op 31/12/2016 naar +0,591 seconden op 01/01/2017. Dit is consistent voor alle punten waar schrikkelseconden werden geïnjecteerd. Maar aangezien UT1 op die datums om middernacht achter UTC lag, zou de waarde van UT1-UTC op die exacte datums nog steeds negatief moeten zijn. Maar dat is het niet.
Misschien is het een proleptische UT1? Of misschien is het UTC, maar dat zorgt voor een beetje een puinhoop met betrekking tot het interpoleren van poolposities over schrikkel tweede grenzen.
Ik was stom aan het doen. Omdat UT1 achter UTC ligt op een punt waar een positieve schrikkelseconde wordt toegevoegd aan UTC, bereikt UT1 middernacht nadat UTC dat doet, wat betekent dat de schrikkelseconde al aan UTC is toegevoegd. De verschuiving van een negatieve UT1-UTC-waarde naar een positieve waarde zal dus plaatsvinden op de dag dat een positieve schrikkelseconde wordt toegevoegd aan UTC. De wijziging wordt pas een dag later zichtbaar als een negatieve schrikkelseconde wordt toegevoegd aan UTC. Maar de kans dat dat gebeurt, is in wezen nihil, aangezien de rotatiesnelheid van de aarde geleidelijk aan vertraagt.
Ja. En daar hoef je je niet veel zorgen over te maken. Transformeer gewoon de tijden naar UTC en gebruik die naar tijden voor de interpolatie. Omdat uw datapunten elke dag uit elkaar staan, is de maximale fout in de interpolatie een fractie van een seconde. Als u zich zorgen maakt over dat soort nauwkeurigheidsproblemen, kunt u een uitzondering maken voor dagen waarop een schrikkelseconde is toegevoegd.
UTC is niet uniform; het heeft schrikkelseconden. Dat gezegd hebbende, een fatsoenlijk (zelfs niet geweldig) interpolatie-algoritme kan niet-uniforme abscissen aan. Wat ik wil is een manier om TAI-UT1 en X- en Y-poolposities te bepalen als functies van UT1 of TAI. Ik beschouw UTC als iets dat alleen voor civiel gebruik bestemd is; het was naar mijn mening een vergissing om UTC aan zowel UT1 als TAI te koppelen, en dit op het tweede niveau te doen. Dit heeft geleid tot een aanzienlijke verwoesting en met een verwaarloosbaar voordeel. Maar dat is water onder de brug.
@DavidHammen Absoluut, door tijden in TAI te veranderen en vervolgens de interpolatie uit te voeren, worden de meeste complicaties verwijderd. U kunt uw geïnterpoleerde waarden terugbrengen naar UT1 of UTC.
UT1 heeft altijd een "dag" van 86400 "astronomische seconden", zodat het verloop van 86400/24: 00: 00 één echte, volledige aardrotatie betekent, wat er ook gebeurt. Dit betekent _niet_ hetzelfde als metrische (SI) seconden en variëren in lengte, hoewel een mens het verschil niet zal kunnen waarnemen. TAI, en dus UTC, vink de metrische tijd aan, niet de astronomische tijd. TAI is een eenvoudige, echte lineaire klok (actueel op 1.942 4867 Gs vanaf het jaar 1958 ten tijde van deze publicatie), UTC probeert echter zichzelf aan te passen zodat de waarde van de tijd van de dag (TOD) binnen 1 s van die van UT1 ligt door seconden toe te voegen of te verwijderen ("schrikkelseconden").
Daarom is het omzetten van UT1 naar TAI niet eenvoudig. Je hebt in wezen een grafiek nodig van de lengte van de astronomische seconden in echte metrische seconden sinds het TAI-tijdperk en dan integreer je dat. En veel succes met extrapolatie van de schaal naar het verleden ...
IMO we moeten gewoon "de oceaan koken", TAI gebruiken als de basis van tijdregistratie direct (gewoon mod 86400, alsjeblieft, er is een tijd van de dag voor civiel gebruik, wat maakt het uit dat de middag zo nauwkeurig is) en de rotatie van de aarde in kaart brengen intervallen erop als een secundaire opname voor astronomische doeleinden (wat eigenlijk een grafiek zou moeten zijn van _hoek_ versus _tijd_.). Maar meh, we zijn ver boven onze hoofden begraven in legacy cruft: g:
FSimardGIS
2019-07-16 21:59:24 UTC
view on stackexchange narkive permalink

Blijkbaar publiceert de IERS waarden voor elke 0 uur UTC in hun bulletins. Zelf dacht ik daar anders over, maar ik merkte onlangs tijdens een geodesie-examen dat ze UTC noemden voor de dagelijkse parameters.

Bij nader inzien van de Bulletins zelf, kon ik dit bevestigen:

enter image description here

Hoewel het gebruik van UT1 in plaats van UTC voor interpolatie slechts kleine fouten zou moeten veroorzaken, kleiner dan de geposte fouten van de uiteindelijke waarden.



ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 4.0-licentie waaronder het wordt gedistribueerd.
Loading...