Skudsekund 1 juli 2015!

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?

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

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.

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.

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 :)

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)

Er det korrekt, at der i princippet kunne forkomme negative skudsekunder?

Hvis det er korrekt - har de så nogensinde forekommet?

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.

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.

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.

Jeg er slet ikke sikker på at jeg kan nå at stille havemøblerne ind og tage dem ud igen på så kort tid!

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

"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. :-)

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.

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)

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.

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.

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:

Hvis nu ens elmåler er synkroniseret op mod NTP, så vil man skulle betale for et sekund ekstra :-)

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.

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?

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.

Da jeg gik til navigation var et buesekund 30.87m ved ækvator. (1852/60)m

Du sammenblander med sommertid / vintertid

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.

Nej, det ville gøre det langt værre

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.

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.