Skudsekund 1 juli 2015!

Der er netop indløbet Bulletin C fra IERS:

Der bliver indsat et skudsekund UTC midnat 30 juni 2015.

Dvs. 01:59:60 lokal dansk sommertid 1. juli 2015.

Overvej at planlægge nedetid.

Historisk gør op imod ¼ af alle NTP servere på nettet skudsekunder forkert.

Jeg modtager meget gerne rapporter om hvorledes det går, til brug i den videre debat om skudsekundernes fremtid.

phk

Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Max Tobiasen

Hvorfor indfører man et skudsekund d. 1 juli, og hvorfor bliver det først annonceret nu?

Umiddelbart ville jeg (som er totalt uvidende om skudsekunder..) tro at det letteste ville være at indkorporere det i slutningen af februar i forlængelse af et almindelige skudår. Ligeledes ville jeg tro at det var noget man havde styr på lang tid i forvejen, og ikke at der som her først kommer en meddelelse om det ½ år før.

Er der en god grund, eller er det bare sådan det er endt med at være?

  • 2
  • 0
Peter Makholm Blogger

Ligeledes ville jeg tro at det var noget man havde styr på lang tid i forvejen, og ikke at der som her først kommer en meddelelse om det ½ år før.

Det er denne antagelse der er forkert.

Skudår bruges fordi et år ikke består af et helt antal dage, men reglen er helt regulær. Skudsekunder skyldes derimod at jordens omdrejningstid ikke er helt regulær og der derfor ikke kan opstilles regler for hvornår der er behov for et skudsekund.

Læs mere på http://en.wikipedia.org/wiki/Leap_second#Slowing_rotation_of_the_Earth

  • 8
  • 0
Torben Mogensen Blogger

Det ville være en del enklere, hvis man bare lod tiden skride i forhold til solen. Den tidsforskydning, der vil komme mellem kl. 12 middag og solens højeste position er minimal, og det er alligevel ret få steder, hvor solen er i apex kl. 12.

  • 4
  • 0
Lars F. Jensen

og det er alligevel ret få steder, hvor solen er i apex kl. 12

Nu svarer 4 sekunder til en sømil (ca 1852m) Ø-V ved ækvator og godt det halve her hos os. Nu bliver GPS vel løbende justeret, men helt nøjagtig tid er og især var ganske vigtig for astronomisk navigation. GPS kom først i 100% dækkende drift engang efter 1992. Vi brugte fortsat sekstant og de noget uregelmæssige Transit satellitter til navigation i 1990.

Det er kun det borgerlig samfund, der arbejder med tidszoner, al navigation er meget nøjeregnende med tiden.

Bliver der udsendt en 1 sek korrektion til almanakken, eller ?

Lars :)

  • 2
  • 0
Poul-Henning Kamp Blogger

Nu svarer 4 sekunder til en sømil (ca 1852m) Ø-V ved ækvator og godt det halve her hos os.

Overvej hvad en times sommertid svarer til ?

Overvej at hele Kina er en enkelt tidszone.

Det er kun det borgerlig samfund, der arbejder med tidszoner, al navigation er meget nøjeregnende med tiden.

Vis mig lige en eneste der laver astronomisk navigation uden en nautisk alamanak at slå op i ?

Den kan fint indeholde DUT1 hvis det skønnes nødvendigt for langskæggede søfolk.

  • 3
  • 0
Thue Kristensen

Alle godt designede systemer som behandler tid, for eksempel databaser, gemmer timestamps i universaltid, ikke i lokaltid. Universaltid har diverse fordele:

  • Et universaltids-timestamp refererer til et unikt tidspunkt, hvor et lokaltids-timestamp kan betyde to tidspunkter i forbindelse med skift mellem vinter og sommertid.
  • Universaltid går aldrig baglæns (sommer og vintertid), er kontinuert og monotont stigende.

Et godt designet system arbejder internt med en regulær tid, og konverterer kun til lokaltid når tiden skal vises til slutbrugeren.

Det samme burde være gældende for skudsekunder. Computere burde internt arbejde med antallet af sekunder siden 1970 (TAI), og så kun konvertere med skudsekunder og tidszone når resultatet skulle vises til slutbrugeren. Man kunne eventuelt få en liste over skudsekunder fra NTP-serveren. Når PHK foreslår at "Overvej at planlægge nedetid.", så er det et resultat af at NTP og diverse operativsystemer ikke bygger på TAI, men så og sige kører deres hardware-clock i "lokaltid". Med diverse bugs til følge når lokaltiden opfører sig mærkeligt i forbindelse med skud-tidsenheder.

  • 3
  • 1
Tobias Tobiasen

Jeg har aldrig forstået skudsekunder. Jo, bevares jeg forstår godt at jordens rotation er uforudsigelig osv. Men hvorfor skal vi indføre skudsekunder af den grund? Langt de fleste mennesker i verden ville aldrig opdage det hvis vi ikke havde skudsekunder. Hvad med at astronomerne bare husker at tage højde for at jorden drejer lidt for langsomt og så lade resten af verden have et mere forudsigeligt tidssystem.

  • 1
  • 0
Esben Nielsen

Jeg er helt enig:

Det vi har brug for i "et system" er en stabilt kørende, monotont voksende tid. Hvordan den forholder sig til vores menneskelige ure er blot en "display" ting. At "et system" i praksis kan være de fleste computere, gør at den bedste kandidat er TAI.

Desværre er UNIX og NTP blevet designet omkring UTC tid. Det vil klæde IT folk at forsøge at rette denne 40 år gamle designfejl i stedet for at skyde på andre:

POSIX kunne udvides med API'er til TAI. CLOCK_TAI er vist allerede foreslået. Linux og/eller xBSD kunne begynde at lade kernen køre i TAI frem for UTC og oversætte ved API kald. NTP kunne begynde at tilbyde en variant af protokollen, som kører i TAI frem for UTC. Efterhånden kunne vi så få skubbet oversættelsen fra TAI -> UTC helt ud der, hvor det høre til: I display koden.

  • 4
  • 0
Christian Bruun

Det er helt klart 3 kvarter værd at se det:

Jep, underholdende. Mht. paven og definitionen på et år, så husker jeg fra min historieundervisning, at det var noget kirken brugte mange kræfter på at få i hus, blandt noget med at påsken skulle ligge samme sted hvert år. (En anden stor religion har jo forsøgt noget lignende, dog ramte deres gud lidt ved siden af og derfinerede året som 353-355 dage)

  • 0
  • 0
Jesper Louis Andersen

Hvis virksomheden er Google, så ender man i det her problem. Deres løsning var at patche alle deres interne stratum 2 servere til at smeare skudsekundet ud over et vindue:

http://googleblog.blogspot.dk/2011/09/time-technology-and-leaping-second...

Det virker nok, men kræver at du har umådeligt godt styr på om dine systemer nu også gør det rigtige i denne forbindelse. Specielt skal du a priori have testet og vide at dine systemer gør det rigtige.

Erlang har naturligvis support for smearing indbygget, da det oftest bliver benyttet til at køre systemer der ikke kan tåle at tages ned. Kaldet til "now/0" er garanteret monoton (Og strictly so). Men du skal stadig have tungen forbandet lige i munden. Et kald til "os:timestamp/0" har alle problemerne PHK hinter om. Så bare fordi du har værktøjet, så er det ikke ensbetydende med at systemet opfører sig ordentligt.

  • 1
  • 0
Niels Danielsen

Nu er det jo hverken ITU, Paven, eller FN der er der bestemmer over IETF, Linux, og BSD.

Måske kunne PHK lave noget lobby arbejde sammen med David Mills og ntp.org. Step 1: NTPv5 protokollen skal udvides til at kunne sende TAI samtidig med UTC, og PHK kunne måske lave et reference design?

Samarbejde mellem Linus og Theo :-) Step 2: Linux og BSD kernen skal udvides med et API'er til håndtering af monoton TAI tid.

Step 3: Der skal laves biblioteks funktioner til at arbejde på TAI tidsstempler. F.eks. formatering af TAI til lokal tz, og skudsekund.

  • 0
  • 0
Niels Danielsen

Du kommer under alle omstændigheder til at betale for skudsekundet, hvordan forestiller du dig du skulle kunne slippe ?

Hvis vi nu har en elmåler der sampler en strøm og en spænding i en buffer over en netperiode. Derefter beregnes effekten P ud fra en RMS beregning, som opdateres hvert netperiode. Energien E[J] der er forbrugt i netperioden beregnes så ved at gange P med længden af netperioden, fra et ntp styret ur. Derefter summeres den målte energi sammen i en kWh tæller.

Hvis vi nu vil udtvære et skudsekund over 1 minut, så vil der i stedet for 61 sekunder, være 60 sekunder der i gennemsnit vil være 1.016 sekunder lange.

Hvis vi forbruger 100W, vil der over de 61 sekunder, forekomme 3050 netperioder af 20ms, hvilket giver 30500.02100=6100J. Men da uret går 1.6% for hurtigt vil der forekomme, 3050 netperioder som fejlagtigt bliver målt til at være 19.67 ms lange, hvilket giver 3050*0.0197 *100=6000J.

Dvs. at vi bliver afregnet for et sekund mindre.

  • 0
  • 0
Niels Danielsen

Nu forudsætter du jo, at skudsekundet bredes ud over et helt minut. Det er muligvis en korrekt antagelse

Nej, det er kun et regne eksempel. Det må foregå over timer, da man ikke kan nå at styre PLL'en op i hastighed og ned igen ned igen inden for 10 min, med den langsomme sample hastighed som NTP normalt anvender.

Hvis mit regneeksempel var lavet over en time, vil der stadig mangle et sekund, men målefejlen (den gennemsnitlige) i perioden vil være meget mindre 1/3601 vs. 1/61.

Nu er dette i praksis ikke noget problem da man normat ikke vil bruge NTP til dette formål, samt at hvis skudsekundet er spredt ud over timer er fejlen nede under måle nøjagtigheden for de fleste processer. Det vil ikke have nogen betydning for vores El-afregning.

men vil dit forbrug ikke også øges med 1.6% hvert sekund i den periode?

Det er relativistisk, det afhænger af hvilket ur du anvender. :-) Nej, effekten er konstant i mit eksempel.

  • 0
  • 0
Aage Andersen

Det ville lette situationen, hvis man indførte skudminutter i stedet for skudsekunder. Dem, der har brug for en nøjagtigere korrektion, kan jo sagtens indhente den hos myndighederne. I dag er det vel kun astronomer, der har brug for korektionerne.

  • 0
  • 0
Poul-Henning Kamp Blogger

Hvad saa, hvis man gik den anden vej og indførte skudnanosekunder?

Det ville være den løsning der (u)populært kaldes "gummisekunder" fordi du aldrig rigtig ved hvor langt et sekund er.

Man praktiserede faktisk denne løsning fra 1958 til 1972 hvor man justerede længden af det atomare sekund til at passe til jordens rotation.

Det er præcis så tåbelig en ide som det lyder, specielt når man betænker at f.eks meteren der defineret udfra sekundtet nu om dage.

  • 0
  • 0
Aage Andersen

Det ville være den løsning der (u)populært kaldes "gummisekunder" fordi du aldrig rigtig ved hvor langt et sekund er.

Nej. Mit forslag indebærer ikke en en ændring af sekunddefinitionen. Hvorfor har man valgt altid at korrigere med 1 sec? der maa være en optimalværdi for denne korrektion.

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