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
- Bøvlet skudsekund lever på lånt tid
- Denne artikel
- emailE-mail
- linkKopier link
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
Hvad saa, hvis man gik den anden vej og indførte skudnanosekunder?Nej, det ville gøre det langt værre
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.</p>
<p>Det ville være den løsning der (u)populært kaldes "gummisekunder" fordi du aldrig rigtig ved hvor langt et sekund er.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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-seconds.html
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.
- more_vert
- insert_linkKopier link
Hvis nu ens elmåler er synkroniseret op mod NTP, så vil man skulle betale for et sekund ekstra :-)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:
- more_vert
- insert_linkKopier link
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 ?
- more_vert
- insert_linkKopier link
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.Du kommer under alle omstændigheder til at betale for skudsekundet, hvordan forestiller du dig du skulle kunne slippe ?
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.
- more_vert
- insert_linkKopier link
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?Men da uret går 1.6% for hurtigt
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
"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. :-)
- more_vert
- insert_linkKopier link
Men det vel sikkert at formode, at Ntimed har helt styr på den sag. :-)
Det får den i hvertfald, men den kan ikke gøre det bedre end de servere den får tid fra.
- more_vert
- insert_linkKopier link
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:
- more_vert
- insert_linkKopier link
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)
- more_vert
- insert_linkKopier link
Jeg er slet ikke sikker på at jeg kan nå at stille havemøblerne ind og tage dem ud igen på så kort tid!
- more_vert
- insert_linkKopier link
Du sammenblander med sommertid / vintertid
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
Er det korrekt, at der i princippet kunne forkomme negative skudsekunder?
Hvis det er korrekt - har de så nogensinde forekommet?
- more_vert
- insert_linkKopier link
Er det korrekt, at der i princippet kunne forkomme negative skudsekunder?
Ja og med den nuværende ujævne udvikling i DUT1 er det faktisk ikke helt usandsynligt at det sker i vores levetid.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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)
- more_vert
- insert_linkKopier link
ntpq -c rv viser ikke noget leap endnu
Det skal den tidligst gøre 1 juni.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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 :)
- more_vert
- insert_linkKopier link
Da jeg gik til navigation var et buesekund 30.87m ved ækvator. (1852/60)m
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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?
- more_vert
- insert_linkKopier link
Hvorfor indfører man et skudsekund d. 1 juli, og hvorfor bliver det først annonceret nu?
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.
- more_vert
- insert_linkKopier link
Det er denne antagelse der er forkert.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.
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
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link