Bøvlet skudsekund lever på lånt tid

Det ligger fast, at der skal indsættes et skudsekund den 30. juni 2015. Men det kan meget vel blive sidste gang, it-systemerne skal slås med den uforudsigelige tidsforskydning.

Det er nok de færreste af dem, der ligefrem går med armbåndsur, som sidder klar ved midnat den 30. juni i år for at justere deres ur for at tage hensyn til det skudsekund, som for nylig blev annonceret. Og det kan muligvis også blive sidste gang, softwareudviklerne skal tage hensyn til skudsekunder, skriver Wired.

Læs også: Skudsekund 1 juli 2015!

Det første skudsekund optrådte i 1972, og i år er det 26. gang, tiden skal justeres på denne måde. Men praksissen med skudsekunder har flere gange været til debat, og det vil endnu en gang blive drøftet til efteråret, når International Telecommunications Union mødes.

Skudsekunder blev indført i UTC-tidsstandarden for at gøre det muligt at kompensere for de uforudsigelige variationer, som opstår i Jordens rotationshastighed, hvor eksempelvis jordskælv over tid kan ændre hastigheden.

En ændring i rotationshastigheden betyder, at der vil være en lille forskel døgnets længde, som over lang tid ville betyde, at soltiden ville afvige fra den tid, computerne registrerede. Altså kunne klokken være midnat på uret, før solen er gået ned.

I praksis er tidsforskellen meget lille, hvilket kan ses ved, at der er tale om skudsekunder. Men for computersystemer, som følger UTC, indebærer det, at de skal kunne håndter, at der bliver tilføjet eller fjernet et sekund. Vel at mærke ikke med faste intervaller, som det er tilfældet med skudår, men ud fra astronomiske observationer og en beslutning truffet af International Earth Rotation and Reference Systems Service, som administrerer skudsekunderne.

Læs også: Ekstra sekund nedlægger it-systemer på stribe

Et alternativ kunne være at acceptere de trods alt meget små afvigelser i rotationshastigheden og i stedet benytte en tidsstandard, som udelukkende er baseret på eksempelvis svingninger i cæsium-atomer, sådan som det sker i atomure, uden at justere tiden i forhold til Jordens rotation.

Når computersystemerne skal håndtere, at der som i år optræder 61 sekunder i det sidste minut i juni måned, så har det flere gange ført til nedbrud. Spørgsmålet er derfor fra it-branchens perspektiv, om en afvigelse, der vil være mindre end ét minut i løbet af et århundrede, er en lille pris at betale i forhold til at undgå it-problemer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Maciej Szeliga

Når computersystemerne skal håndtere, at der som i år optræder 61 sekunder i det sidste minut i juni måned, så har det flere gange ført til nedbrud. Spørgsmålet er derfor fra it-branchens perspektiv, om en afvigelse, der vil være mindre end ét minut i løbet af et århundrede, er en lille pris at betale i forhold til at undgå it-problemer.

Vi kunne også (med nøjagtigt samme argumentation) fjerne skuddagen og i øvrigt sørge for at alle måneder er lige lange (jeg vil anbefale 17 måneder á 21 dage eller 13 måneder á 28 dage for så går det også lige op med ugerne). ;-)

  • 1
  • 6
#2 Lars Hansen

Hvis der kun har været 26 justeringer på 43 år, så vil tiden på 3300 år skride knap godt ½ time. Om 3300 år er året også skredet med én dag. Kan vi ikke bare nu aftale at vi om 3300 år indsætter én ekstra dag og én ekstra time og alle er glade og vi kan vente yderligere 3300 år med at indsætte en ekstra dag i året.

  • 0
  • 0
#3 Bent Jensen

"Kan vi ikke bare nu aftale at vi om 3300 år indsætter én ekstra dag og én ekstra time og alle er glade og vi kan vente yderligere 3300 år med at indsætte en ekstra dag i året." @Lars Hansen

Så er et ur med viser der ikke går bedre, det passer 2 gange om dagen, det andet en gang hver 1650 år.

Men ud over at miste en dag, så ved jeg ikke om vi så i stedet skal flytte arbejdstider. Så vi ikke alle skal arbejde NAT.

  • 0
  • 0
#4 Esben Nielsen

Grundlæggende er det for slapt, at IT folks dovenskab skal bestemme over vores tidsangivelse. IT systemer skal være vores værktøjer, ikke vores herrer!

Den rigtige løsning ville være at bruge TAI som den grundlæggende tidsangivelse i alle IT systemer og protokoller, og så oversætte til UTC så tæt på bruger-præsentation som muligt. Det gør GPS systemet allerede, men er tvunget til at oversætte til UTC for f.eks. at kunne NMEA beskeder ud.

Men da rigtigt mange protokoller refererer til UTC tid vil der være en stor opgave, at lave nye versioner af dem alle.

Men vi kunne holde fast i UTC som TAI-16s og indføre Universal Astronomical Time (UAT*), som indeholder fremtigdige skudsekunder. Oversættelse til lokal tid er skal fremover være relativ til UTCv2. F.eks vil CET være UAT + 1 time, som så eftner næste skudsekund vil være UTC + 59min59s.

Det er jo i bund og grund en ren definitionssag... Det aller vigtigste er, at IT systemer er enige om, hvad klokken er i universal tid** OG man i alle tidsangivelser er enige om, hvordan man oversætter.

*Hvis UAT er ledig som tidszone. Alternativ: ERT (Earth Rotation Time)

**Relativistiske effekter giver en grænse for, hvor enige forskellige systemer kan være, men det er så langt nede, at det for alle IT-praktiske formål kan ignoreres.

  • 3
  • 1
#5 Niels Danielsen

@Esben Jeg er enig med i at vi skal distribuere en monoton tid, og så formatere den til UTC på bruger præsentations tidspunktet.

Men da rigtigt mange protokoller refererer til UTC tid vil der være en stor opgave, at lave nye versioner af dem alle

Der er efterhånden meget der anvender NTP, så vi kunne starte her. Jeg vil foreslå at udvide NTP til også at kunne distribuere både UTC og TAI. Så vil programmer der anvender de gamle API'er fortsat fungere uændret. Og de nyt software vil kunne få adgang til en monoton wall clock med ns opløsning, og ms nøjagtighed.

Det eneste problem er hvor gammelt og nyt software kommunikere sammen skal man sikre sig at det ikke giver problemer da de to kan være op til 1 sec. Forskellige. I praksis skal man beholde UTC i de gamle protokoller indtil at de er blevet defineret om til at anvende TAI.

*Hvis UAT er ledig som tidszone. Alternativ: ERT (Earth Rotation Time)

Jeg vil gerne frabede mig at tidszone, og sommertid, samt skud sekund er kombineret i en attribut. Hvis vi nu har to tidsstempler med fuld information: (Ikke nødvendigvis indkodet således) TAI=2015-Jan-09 07:45 LeapSec=26 Tz=UTC+1 StandardTime TAI=2015-Aug-19 17:45 LeapSec=27 Tz=UTC+1 DaylightTime

Så kan de præsenteres på samme må som da de blev genereret, man kan betegne tidsforskellen på forskellige måder som feks 'kalender tid', og som antal TAI sekunder. Et invalidt LeapSec felt kunne bruges til at indikere at det er en tid i fremtiden, hvilket kan bruges til at sætte en timer til enten 'kalender tid', eller TAI sekunder.

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