Skudsekund 1 juli 2015! | Version2
Skudsekund 1 juli 2015!
Af Poul-Henning Kamp@bsdphk Mandag, 5. januar 2015 - 15:31 34
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.
Max Tobiasen Mandag, 5. januar 2015 - 15:57
Hvorfor indfører man et
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?
Peter Makholm Mandag, 5. januar 2015 - 16:12 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
Max Tobiasen Mandag, 5. januar 2015 - 16:21
tak for svaret - det giver god mening. Jeg har altid bare antaget at jordens rotation var kendt og kunne udregnes langt ind i fremtiden. Det er så åbenbart ikke korrekt.
Poul-Henning Kamp Mandag, 5. januar 2015 - 16:42 Blogger
Fordi forskellen på jordens rotation og UTC tidsskalaen risikere at overstige 0.9s inden 1 juli.
Fordi vi altid kun får max seks måneders varsel.
Torben Mogensen Mandag, 5. januar 2015 - 16:45 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.
Lars F. Jensen Mandag, 5. januar 2015 - 17:24
Re: Let it slide
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 ?
Poul-Henning Kamp Mandag, 5. januar 2015 - 19:05 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.
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.
Kim Sindalsen Mandag, 5. januar 2015 - 20:37
Jeg påstår overhovedet ikke dette er forkert, og jeg ved ikke om min (ntp2.vlh.dk) håndterer det rigtigt. Men jeg går udfra/håber det er nok at downloade leap-seconds filen fra time.nist.gov og opdatere config -> reloade ntp?
(nej, det har jeg ikke gjort endnu - sker 1/4, så ntpq -c rv viser ikke noget leap endnu)
Poul-Henning Kamp Mandag, 5. januar 2015 - 20:50 Blogger
Re: 25% NTP-servere håndterer skudsekund forkert?
ntpq -c rv viser ikke noget leap endnu
Det skal den tidligst gøre 1 juni.
Eskild Nielsen Mandag, 5. januar 2015 - 21:54
negative skudsekunder?
Er det korrekt, at der i princippet kunne forkomme negative skudsekunder?
Hvis det er korrekt - har de så nogensinde forekommet?
Thue Kristensen Tirsdag, 6. januar 2015 - 0:26
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.
Knud Jensen Tirsdag, 6. januar 2015 - 2:10
Re: negative skudsekunder?
I princippet ja. Men det er vist aldrig sket inden for UTC standarden.
Jorden rotation bliver langsommere over tid. For at ændre den udvikling skal der nok noget drastisk til.
Tobias Tobiasen Tirsdag, 6. januar 2015 - 8:37
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.
Thomas Nielsen Tirsdag, 6. januar 2015 - 9:28
Det er ikke lang tid; 1 sekund
Jeg er slet ikke sikker på at jeg kan nå at stille havemøblerne ind og tage dem ud igen på så kort tid!
Poul-Henning Kamp Tirsdag, 6. januar 2015 - 10:26 Blogger
Ja og med den nuværende ujævne udvikling i DUT1 er det faktisk ikke helt usandsynligt at det sker i vores levetid.
Mads Claus Henriksen Tirsdag, 6. januar 2015 - 10:35
PHK har faktisk holdt et foredrag, hvor han på videnskabelig (og nørde-sjov) vis forklarer om skudsekunder.
Det er helt klart 3 kvarter værd at se det:
https://www.youtube.com/watch?v=5rmEDFFLoYU
Carsten Gehling Tirsdag, 6. januar 2015 - 11:34
"Historisk gør op imod ¼ af alle NTP servere på nettet skudsekund"
Men det vel sikkert at formode, at Ntimed har helt styr på den sag. :-)
Esben Nielsen Tirsdag, 6. januar 2015 - 11:39
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.
Poul-Henning Kamp Tirsdag, 6. januar 2015 - 11:53 Blogger
Re: "Historisk gør op imod ¼ af
Det får den i hvertfald, men den kan ikke gøre det bedre end de servere den får tid fra.
Christian Bruun Tirsdag, 6. januar 2015 - 12:14
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)
Jesper Louis Andersen Tirsdag, 6. januar 2015 - 12:22
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.
Niels Danielsen Onsdag, 7. januar 2015 - 19:44
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.
Niels Danielsen Onsdag, 7. januar 2015 - 19:55
Hvis nu ens elmåler er synkroniseret op mod NTP, så vil man skulle betale for et sekund ekstra :-)
Poul-Henning Kamp Onsdag, 7. januar 2015 - 20:50 Blogger
Du kommer under alle omstændigheder til at betale for skudsekundet, hvordan forestiller du dig du skulle kunne slippe ?
Niels Danielsen Onsdag, 7. januar 2015 - 22:51
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.
Peter Stricker Torsdag, 8. januar 2015 - 0:06
Men da uret går 1.6% for hurtigt
Nu forudsætter du jo, at skudsekundet bredes ud over et helt minut. Det er muligvis en korrekt antagelse, men vil dit forbrug ikke også øges med 1.6% hvert sekund i den periode?
Niels Danielsen Torsdag, 8. januar 2015 - 7:39
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.
Bo Nielsen Torsdag, 8. januar 2015 - 8:53
Da jeg gik til navigation var et buesekund 30.87m ved ækvator. (1852/60)m
Bo Nielsen Torsdag, 8. januar 2015 - 8:58
Re: Det er ikke lang tid; 1 sekund
Du sammenblander med sommertid / vintertid
Aage Andersen Mandag, 2. marts 2015 - 17:01
Hvorfor 1 sek ?
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.
Poul-Henning Kamp Mandag, 2. marts 2015 - 19:35 Blogger
Re: Hvorfor 1 sek ?
Det ville lette situationen, hvis man indførte skudminutter i stedet for skudsekunder.
Nej, det ville gøre det langt værre, fordi så ville det være 100 års produktion af software der ikke var testet.
Aage Andersen Onsdag, 4. marts 2015 - 21:05
Nej, det ville gøre det langt værre
Hvad saa, hvis man gik den anden vej og indførte skudnanosekunder?
Poul-Henning Kamp Onsdag, 4. marts 2015 - 22:09 Blogger
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.
Aage Andersen Fredag, 6. marts 2015 - 5:20
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.