Negative skudsekunder i sigte

Skudsekunder er noget rod, men det er muligvis ved at blive endnu værre.

En lang historie, kort fortalt: Jorden mister rotationsenergi, primært på grund af og til månen, via tidevandskræfterne og derfor bliver dagene længere:

Illustration: Robert Seaman

Det tog man ikke højde for da man definerede vores moderne tidsenheder:

Illustration: Robert Seaman

For halvtres år siden sloges man om det var jorden eller cæsium atomer der skulle være grundlaget for vores tidsregning og det quasisalomoniske resultat blev at cæsium atomer bestemmer sekundets længde, mens direktøren for Paris Observatoriet bestemmer hvor mange af disse sekunder der er i hver atronomisk måned.

Med andre ord: Han/Hun indsætter et skudsekundt en gang imellem, således at stjernerne ikke driver bort fra deres positioner set fra jorden.

At Jorden mister rotationsenergi på den lange tidsskala er ikke det samme som at den roterer stadigt langsommere, vi aner faktisk intet om hvad der foregår i det meste af Jordens indre og med den præcision vi arbejder her, et sekund på et år er ca. 30 milliardtedele, er en masse relevant geofysik helt ukendt land for os, vi ved meget, meget lidt om hvad der foregår fra 10km under os og videre ned.

Når vi plotter dagens længde de sidste 50 år ser det således ud:

Illustration: IERS

Bemærk den tydelige årlige "støj": Stort set alle træer står på den nordlige halvkugle og som når en balletdanser trækker armene ind til kroppen, roterer jorden en smule hurtigere når løvet falder på den nordlige halvkugle.

Integrerer man denne kurve får man forskellen på jord-rotations-tid og atom-tid og så kan vi endelig se skudsekunderne:

Illustration: IERS

Da man vedtog reglerne for skudsekunder for et halv århundrede siden, var man så meget på herrens mark at man tillod direktøren for Observatoire Paris både at indsætte og fjerne skudsekunder og det sidste har vi i branchen grinet meget af lige siden, for jorden mister jo rotationsenergi, hvordan skulle den kunne give sig til at køre hurtigere rundt ?

De sidste pår år på de to nederste kurver har fået grinet til at stivne lidt, for negative skudsekunder begynder faktisk at se sandsynlige ud i løbet af det næste årti.

Rent fysisk aner vi stadig ikke hvad der foregår, det kan f.eks være at "glidefladerne" mellem jordens kerne og skorpe er blevet glattere, det kan måske være alt det is vi har smeltet af gletschere som nu er vand mange hundrede meter tætter på jordens centrum, det kan være at atmosfæren vejer mindre (også klimaforandringer) og mest sandsynligt er det lidt af det altsammen, plus nogle ting vi endnu ikke har opdaget.

En ting er dog helt sikkert: Vi har aldrig nogensinde tidligere haft et skudsekund hvor uret skifter direkte fra 23:59:58 til 00:00:00.

Den gode nyhed er at der er folk der har testet at det virker med deres software.

Den dårlige nyhed er at jeg er formodentlig på fornavn næsten alle sammen.

Mit personlige gæt er at vi får et negativt skudsekund inden klokken 03:14:07Z d. 19 januar 2038.

phk

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Poul Kristiansen

Hej Poul-Henning,

Jeg arbejder selv indenfor rumfart og her er det vigtigt at holde styr på skudsekunderne når man taler om baneberegning, osv.

Jeg husker, mener jeg, at du tidligere har skrevet om bestræbelser på at afskaffe skudsekunderne og lade tiden "drive". Har du nye informationer angående dette?

Venlig Hilsen, Poul

  • 0
  • 0
#3 Michael Jensen

Hvis man vil beholde skudsekunder vil jeg stadig foreslå at man summere skudsekunderne i et skudsekund offset, som man så lægger til sin standard tid ligesom man lægger tidszonerne til.

  • 2
  • 0
#4 Henrik Størner

men hvordan skal jeg forstå grafen derhen at de negative skudsekunder er på vej? Så vidt jeg kan se holder grafen med UT1-UTC tæt på nul i det der er plottet ind mod 2021 med en udfladende tendens - og hvis de to ikke divergerer ret meget, så burde der vel slet ikke være brug for at indsætte skudsekunder?

  • 0
  • 0
#5 Poul-Henning Kamp Blogger

men hvordan skal jeg forstå grafen derhen at de negative skudsekunder er på vej?

Fordi det ser ud som om den andennederste kurve, LOD, muligvis er på vej til at ligge under 86400 sekunder per døgn lang tid nok til at integralet af denne kurve, fratrukket integralet af atomtiden, kommer over ca. 0.5 sekund

Hvis vi er heldige at den stabiliserer sig omkring 86400 nogle år skal der, som du korrekt observerer ikke bruges skudsekunder (ligesom det skete i dot-com perioden.)

  • 2
  • 0
#7 Esben Nielsen

Problemet er diverse IT-systemer og protokoller (NTP) bruger UTC og ikke TAI, som er UTC uden skudsekundet.

GPS kører TAI i internt og sender en almanak indeholdende bl.a. skudsekundet ud periodisk. Problemet kommer først i systemklikken og NTP, hvor det måske ikke korrekte skudsekund skal ligges til. Lod man være med det og kun brugte det i, når man skriver tiden ud, præcist som sommertid og tidszoner (i moderne systemer uden for Kina i hvert fald), ville problemet være væk.

  • 1
  • 0
#8 Magnus Jørgensen

Hvorfor ikke håndtere skudår, skuddage og skudsekunder på samme måde som tidzoner, hvor det er en form for localisation der bestemmer hvordan den viste tid er representeret? Således kan computer tid på jorden være indstillet præcist efter et atom ur og på den måde er det kun den visulle representation der tager højde for ændringerne.

  • 2
  • 0
#11 Jonas Høgh

GPS kører TAI i internt og sender en almanak indeholdende bl.a. skudsekundet ud periodisk. Problemet kommer først i systemklikken og NTP, hvor det måske ikke korrekte skudsekund skal ligges til. Lod man være med det og kun brugte det i, når man skriver tiden ud, præcist som sommertid og tidszoner (i moderne systemer uden for Kina i hvert fald), ville problemet være væk

Det er en udbredt misforståelse, at det kurerer alle problemer med tidszoner og sommertid at persistere alting som UTC, og kun betragte lokal tid som en præsentationsdetalje. Det holder bare ikke i praksis. Tag fx et kalendersystem, hvor du ønsker at oprette et møde, der er planlagt til at starte kl 9:00 i København til næste år. Det kan ikke meningsfuldt repræsenteres som et UTC tidspunkt, da vi endnu ikke ved, om Danmark til den tid befinder sig permanent på offset +01:00 eller +02:00, når sommertid er afskaffet i EU.

  • 1
  • 0
#13 Poul-Henning Kamp Blogger

Hvorfor ændret man UTC i stedet for at lægge det ind i timezone databasen og håndtere det på samme måde som sommertid?

Det var sådan set de USA prøvede at haste igennem da der i 2005 begyndte at komme udsigt til et skudsekund igen og det var gået op for dem at alle de IT systemer de havde købt, specielti DoD, de sidste ti år ikke var testet for og næppe håndterede skudsekunder rigtigt.

Det fik den gamle "krig" mellem astronomer og fysikere til at bryde ud i lys lue igen og retronationale politikere blandede sig også, f.eks i England.

  • 1
  • 0
#15 Poul-Henning Kamp Blogger

Det er en udbredt misforståelse, at det kurerer alle problemer med tidszoner og sommertid at persistere alting som UTC, og kun betragte lokal tid som en præsentationsdetalje.

Min tommelfinger-regel:

Alle tidspunkter i fortiden bør lagres i UTC

Alle tidspunkter i fremtiden bør lages præcis som brugeren inddaterede dem og fortolkes efter de regler der gælder til den tid.

Hvorledes man forholder sig til brugers enheds ide om hvad klokken er kræver at man holder tungen lige i munden.

Hvis man f.eks går ind på dinstation.dk med en computer i en udansk tidszone, herunder UTC kører det helt zig-zag.

Uret øverst i højre hjørne i enhedens tidszone, lige nu 20:47 for mig med UTC.

Nedtællingen til et tog om 10 minutter siger at der er 130 minutter(!)

Men køreplaner og afgangstider ser OK ud.

  • 2
  • 0
#16 Flemming Kaa Madsen

Løv vejer i størrelsesordnen 1 til 6 kg m2. Men der er også en betydelig opstigning af vand i stammer og grene. Træerne er mellem 20 og 60 meter høje. 1000 til 10000 tons pr. km2 hævet og sænket 30 meter. På rent lutterkik og med betydelig afskovning i mente er Europas areal på ca. 10 mio. km2 er rimeligt bud på aralet.

Også er det "bare" at gå videre med hvad det betyder for jordens rotationshastighed. ;-)

  • 1
  • 0
#21 Esben Nielsen

Din regel ser ud til at være:

Brugerundtastede tidspunkter kan først oversættes til f.eks. UTC, når tidszonen er endeligt fastlagt.

Jeg har endnu en erfaring: Brug kun UTC, når tidsstempler skal sammenlignes med andre systemer eller overleve reboot. Mange interne timerne med mere skal køre på CLOCK_MONOTONIC eller tilsvarende. Problemet er, at uret kan hoppe, enten ved at nogen stiller tiden, eller NTP først finder tiden efter nogen tid. Så kan alle timerne time ud samtigdigt eller ikke fyre i lang tid. Det er ofte ikke den opførsel, som var tiltænkt. Desværre bruget meget API CLOCK_REALTIME både i C og Java.

På mit $DAYJOB startede vi med at tidsstemple data med UTC. Men så kunne tidsstempler hoppe baglæns eller der kunne komme hullet i datastrømmen. Det kunne algoritmerne ikke rigtigt tåle. Nu bruger vi noget, der er afledt af CLOCK_MONOTONIC og er monotont stigende. Så holdet vi blot styr på offset til UTC og regner først UTC ud vhja offset, når vi sender data ud til andre systemet, som skal sammenligne med andre data-kilder.

  • 0
  • 0
#23 Flemming Kaa Madsen

"Dertil kommer Rusland, Asien og Nordamerika."

Øh nej Først skal man modregne med Chile, New Zealand og Australien. Derefter skal man finde ud af (i mit tilfælde et meget groft overslag) hvor store områder der er afskovede. I case Danmark er der ca. 4% løvskov+læhegn+hvad der ellers står i haver, parker mm. Hvis det skal omregnes til højskov kommer vi ikke over 10 %. Og et hurtigt googel-map-satelit-kik på Ukraine, Kina, Tyrkiet, Iran fortæller også at betydelige områder er afskovede. USA ser ud til at have den største mængde løvfældende skov tilbage.

Så uden at slå alle data op, er mit bud fortsat et løvfældene areal, der påvirker rotationen af jorden i størrelsordnen Europa.

Jeg overvejede faktisk om jeg skulle gå igang med at regne den anden vej: Hvor stort et skovareal skal være "netto-løvfældende" for at det passer med rotationsændringen. Meeen der er nu nok også en hel del huller i den beregning, når jeg ikke sætter tid af til dataindsamling.

  • 0
  • 0
Log ind eller Opret konto for at kommentere