Google vil sprede skudsekund over 20 timer nytårsaften

Hvert sekund på Googles tidsservere vil være 13,9 mikrosekunder længere end standardtid. På den måde undgår Google at stoppe urene helt for at indsætte skudsekundet.

Nytårsaften skal der tælles et ekstra sekund ned, inden champagnepropper springer. Der bliver nemlig indsat et skudsekund, det 27. af slagsen. De færreste vil bemærke det, men tusindvis af programmer og millioner af servere har brug for altid at holde styr på tiden ned til hvert eneste sekund.

Så når der fra tid til anden skal være 61 sekunder i et minut, så giver det udfordringer. De fleste løser det ved at stoppe uret i et sekund, mens andre tæller et ekstra sekund. Google har valgt en anden tilgang og vil lade tiden i Googles sky gå lidt langsommere end uden for, indtil skudsekundet er en realitet.

Andre vil også kunne læne sig op af Googles tilgang, for hvis man benytter Googles NTP-tidsservere, så får man også skudsekundet med via Googles metode, skriver teknisk chef for Googles Time Team, Michael Shields.

Læs også: Skudsekund gør nedtælling til nytåret ét sekund længere

Skudsekundet finder denne gang sted klokken 23:59:60 UTC, koordineret universaltid. Men Google påbegynder processen klokken 14:00:00.

Fra dette tidspunkt vil Googles tidsservere arbejde med et sekund, der er 13,9 mikrosekunder længere end standardtiden og et SI-sekund.

Lige før skudsekundet indsættes ved midnat, vil Googles ure være et halvt sekund bagefter standardtiden. Ved midnat løber standardtiden med et ekstra sekund, som Googles servere ikke tæller med. Lige efter dette ekstra sekund, vil Googles tidsservere dermed være et halvt sekund foran standardtiden.

Googles tidsservere fortsætter frem til klokken 10:00:00 med de langsommere sekunder, indtil den relativt hurtigere standardtid har indhentet Googles langsommere tid og det halve sekunds forspring, skriver Google i dokumentationen for tidsspredningen.

Google har valgt at lave en lineær udglatning af skudsekundet. I 2011 introducerede Google en udglatning baseret på en cosinusfunktion. Fordelen ved cosinusfunktionen er, at væksten i tidsforskellen mellem Googles tid og standardtid gradvis bliver større og tilsvarende gradvist aftager. Dermed mindsker man det første spring fra et normalsekund til et længere Google-sekund.

Et argument for at gøre det på denne måde var, at man undgik, at serverne fejlagtigt forsøgte at korrigere for den målbare tidsafvigelse, men Google har altså fundet frem til, at en lineær metode fungerer.

Læs også: Bøvlet skudsekund lever på lånt tid

Skudsekunderne er uregelmæssige og afhænger af små afvigelser i Jordens bane og rotationstid, som for eksempel kan påvirkes af store jordskælv. Når der er opbygget tilstrækkelig stor afvigelse, beslutter organisationen International Earth Rotation and Reference Systems Service, at der skal indsættes et skudsekund for at synkronisere mellem tiden målt med atomure og astronomisk tid.

Men denne uforudsigelighed er med til at gøre implementeringen af skudsekunderne er problematisk, og derfor har der i en årrække kørt en debat om, hvorvidt de skal afskaffes, så det er atomurene og ikke astronomisk tid, der alene afgør standardtid på Jorden.

Læs også: Dansk ekspert: Skudsekundets dage er talte

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mads Hjorth

Jeg troede at NTP serverne gjorde rigtig meget for at opfører sig ens, men det ser ud til det er teemmelig velbeskrevet i RFC'en.

I øvrigt spøjst at RFC'en indeholder tabel formattering.... '@Z_TBL_END ='

  • 0
  • 0
Peter Kyllesbeck

I eventloggen optræder dette logget 2017-01-01 00:00:00:

The system time has changed to ‎2016‎-‎12‎-‎31T23:00:00.157227500Z from ‎2016‎-‎12‎-‎31T23:00:00.157227500Z.

Change Reason: System time adjusted to the new time zone.

Jeg troede, det skulle udføres 2017-01-01T00:00:00Z, eller som der stod her ( ca 2017-01-01T01:00:00Z) :
https://www.timeanddate.com/time/leapseconds.html

In Copenhagen, the previous leap second occured on Sunday, 1 January 2017, 00:59:60.
UTC time was 31 December 2016, 23:59:60.

Blev det gjort en time for tidligt?
Har vores hjemlige time-guru, PHK, en forklaring?

  • 0
  • 0
Lasse Lasse

Jeg har ingen anelse, men husk at Z betyder Zulu tidszonen, som så igen for nogen betyder GMT og for andre betyder UTC+0 (Z er tvetydigt).

For nogen betyder GMT så UT1 og for andre betyder det UTC+0 (GMT er tvetydigt). Og da UT1 er "astronomisk" og har skudsekunder sådan, at solen altid er højest kl 12:00 (og dermed varierer med op til 0.6 sek fra UTC+0), så kunne dette være Windows definition af Z?

  • 0
  • 0
Peter Kyllesbeck

Jeg har ingen anelse, men husk at Z betyder Zulu tidszonen, som så igen for nogen betyder GMT og for andre betyder UTC+0 (Z er tvetydigt).


Nu fremgår det af den normale logning i eventloggen, at Z betyder UTC, og at det er den 'normale' måde at angive tidszonen på.

Min undren og spørgsmål gik mere på, om MS tager fejl af, om det skal gøres i UTC-tid eller lokaltid. Noget tyder på, at MS gør det i lokaltid, hvilket vist ikke er korrekt.

Jeg havde forstået, at det skulle gøres 23:59:60 i UTC, som det også fremgår af det tidligere link.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize