Husk: Skudsekund d.30
Nu hvor vi er så tæt på at folk har en chance for at huske det, vil jeg erindre om at der kommer et skudsekund d. 30 juni.
Skudsekundet indsættes umiddelbart imellem 2012-06-30 23:59:59 UTC og 2012-07-01 00:00:00 UTC
Bid mærke I at det er UTC.
I lokaltid er det derfor klokken to, natten mellem lørdag og søndag.
phk
Om Poul-Henning KampPoul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (35)
Tjah Anders, det kan godt være at skudsekunder er en skævhed, men jorden er nu engang skæv.
UTC er defineret på basis af atomure, og er altså (modulo skudsekunder) en tilstræbt lineær tidsskala.
Vi har så skudsekunder ind imellem for at den lineære tidsskala ikke skal komme alt for langt ud af takt med den "faktiske jordiske" tid: vi vil fx nødig have at uret viser 12:00 når solen er ved at gå ned.
Vi har skuddage hvert fjerde år for at kalenderdagen skal blive ved med at passe med årstiden.
Tilsvarende har vi har skudsekunder ind imellem for at UTC-døgnet skal blive ved med at passe sammen med det faktiske soldøgn.
Om det så er umagen værd kan man diskutere. Men det er en smuk påmindelse om at vi bor på en dynamisk planet, hvor referencerammer for både tid og sted løbende må tilpasses for at tidligere målte koordinater skal blive ved med at passe med virkeligheden.
-
7 -
0
PHK: netop - derfor min kommentar om at man kan diskutere om skudsekunder er umagen værd.
Derimod er det stensikkert umagen værd at holde sig for øje at man bor på overfladen af en dynamisk planet, påvirket af både tektoniske og astronomiske kræfter (jordskælv, kontinentaldrift, tideeffekter etc.)
-
2
-
0
Her er en god side med data og baggrundsinformation fra en radioastronom der er sikker på at jorden, eller ihvertfald alle hans teleskoper, går under hvis vi fjerne skudsekundet. Uanset om man deler hans konklusion eller ej, er hans data gode nok.
-
2
-
0
Så skal vi endnu tidligere op her midt i sommertiden.
Men, på den anden side er det vel rimeligt at universets herskere - Homo Sapiens - bestemmer hvor skabet skal stå og hvad klokken er slået.
Jorden er jo trods alt universets naturlige midtpunkt, hvorom alting drejer.
god weekend
-
5
-
1
Vi har så skudsekunder ind imellem for at den lineære tidsskala ikke skal komme alt for langt ud af takt med den "faktiske jordiske" tid: vi vil fx nødig have at uret viser 12:00 når solen er ved at gå ned.
Men det gør det jo allerede hvis uret er stillet til UTC og man står i Calcutta!
Empirisk er det ganske uproblematisk at have en UTC som ikke passer til solens op og nedgang. Man vælger sig bare en lokaltid med et pænt rundt tidszone-offset i forhold til UTC som får lokaltiden til at passe nogenlunde.
Den eneste konsekvens af at fjerne skudsekunderne så jordens rotation tager et par millisekunder længere end et UTC-døgn er at man med et årtusinde eller tos mellemrum skal vælge sig et andet tidszone-offset. Dette er også en uproblematisk operation; vi udfører den rutinemæssigt to gange om året allerede.
Radioastonomerne skal være velkomne til at drive deres udstyr med en særlig radioastronomi-tidsskala der kører med et flytbart offset i forhold til UTC/TAI. Men der er ingen grund til at de skal have lov til at påføre hele resten af verden bevær at den årsag.
-
10
-
0
Jeg böjer mig da hellere lidt for astronomien end overformynderiet omkring sommertiden. Videnskaben har da i det mindste et almennyttigt formål, de eneste målbare resultater af sommertiden er, indtil videre: höjere beskäftigelse på hjerteafdelingerne samt öget tilgängelighed af hjorteköd i udkantsdanmark nogle måder om året.
-
3
-
2
Så skal vi endnu tidligere op her midt i sommertiden
Nej, tværtimod kan du sove længe
-
0
-
0
1 sekund mere søvn vil helt sikkert hjælpe på min skønhedssøvn :)
Mikael Boldt, det er noget af en konklusion at homo sapiens skulle være universets herskere! Men ok vi er jo også "alene" i universet vis man skulle tro bb.
-
0
-
0
Hvis du er afhængig af nøjagtig tid:
Husk også, hvis din GPS-modtager ikke selv tager højde for forskellen, at der nu bliver 16 sekunders forskel imellem GPS og UTC-tid.
-
4
-
0
http://kilder.rundetaarn.dk/observatoriet/VilladsChristensenOmTidssignal...
indholder en for tidsnørder ganske morsom beretning om urtidens stilling i København og hvad Struense dermed havde at gøre.
-
5
-
0
Jeg husker tydeligt hvordan en kammarat og jeg i 90'erne havde en GPS tændt nytårsaften, og udbrød et jubel råb da vi så uret i GPS'en tøve et sekund (det viste ikke 60 i uret).
-
5
-
0
Unix og NTP burde have kørt atomar tid, ikke UTC som internt ur. Så time_t burde have været antal ægte sekunder siden 1/1-1970 og ikke pseudo sekunder som nu. At oversætte til UTC eller en hvilket som helst tidszone, burde have været noget rent display.
Det ville også betyde, at man ville kunne trække to time_t fra hinanden og få den rigtigt tidsforskel. Det kan man ikke med UTC.
-
1
-
0
Vi kan vel ikke vide om Søren ville komme for tidligt eller for sent, for det afhænger jo både af hvad hans eget ur kører efter og hvad arbejdspladsens kører efter. Vi kan bare vide at de ikke kører efter samme tid, for så kunne det jo være lige meget med et skudsekund :-)
-
1
-
0
Unix og NTP burde have kørt atomar tid, ikke UTC som internt ur. Så time_t burde have været antal ægte sekunder siden 1/1-1970 og ikke pseudo sekunder som nu. At oversætte til UTC eller en hvilket som helst tidszone, burde have været noget rent display.
Yep, og POSIX burde have specificeret at minutter består af mellem 59 og 61 sekunder. NTP burde have sendt skudsekund-differencen iflg. serveren med, så man kunne nøjes med at opdatere tidszonen på NTP-serveren.
Problemet er at det er svært at fikse nu. Der er masser af software derude som antager at der er præcist 86400 sekunder i et døgn og at et tidsstempel der ender i :60 er en fejl.
-
0
-
0
Skudsekundet viste sig så at blive et issue hos mig.
Alle Java VM'er på RHEL6 begyndte at udvise meget underlig opførsel (2-300% CPU load over det normale) kort efter kl. 02, og en stop / start af VM'erne hjalp intet. Efter start røg CPU load op på 2-300% igen og maskinens samlede load var også derefter.
Hverken stacktraces, logfiler eller andre ting viste noget der kunne hinte på hvad der var galt, men en enkelt lille linie i messages var dog hjælpsom:
Jul 1 01:59:59 web8 kernel: Clock: inserting leap second 23:59:60 UTC
.. og så var det, at lidt googling fandt mange andre der i dag også havde haft problemer, og en løsning:
date ; sudo date -s "date -u" ; date
Poul-Henning: Hvornår var der sidst et skudsekund, og hvornår ved man det næste kommer?
Jeg skal vist til at holde øje med dem..
-
1
-
0
Skudsekundet viste sig så at blive et issue hos mig.
Alle Java VM'er på RHEL6 begyndte at udvise meget underlig opførsel (2-300% CPU load over det normale) kort efter kl. 02, og en stop / start af VM'erne hjalp intet. Efter start røg CPU load op på 2-300% igen og maskinens samlede load var også derefter.
Hverken stacktraces, logfiler eller andre ting viste noget der kunne hinte på hvad der var galt, men en enkelt lille linie i messages var dog hjælpsom:
Jul 1 01:59:59 web8 kernel: Clock: inserting leap second 23:59:60 UTC
.. og så var det, at lidt googling fandt mange andre der i dag også havde haft problemer, og en løsning:
date ; sudo date -s "date -u" ; date
Poul-Henning: Hvornår var der sidst et skudsekund, og hvornår ved man det næste kommer?
Jeg skal vist til at holde øje med dem..
-
0
-
0
Poul-Henning: Hvornår var der sidst et skudsekund, og hvornår ved man det næste kommer?
I gennemsnit, over 30-40 år kommer det et hver 18 måneder, men de er meget uregelmæssige og annonceres kun 5-6 måneder i forvejen.
Hvis du subscriber til IERS's "Bulletin C" får du besked når skudsekundet bliver annonceret første gang.
-
0
-
0
Hov, jeg beklager dobbeltpost - jeg fik timeout på post fra Varnish, og ville egentlig bare have ventet til senere med at poste.
-
0
-
0
Skudsekundet viste sig så at blive et issue hos mig. Alle Java VM'er på RHEL6 begyndte at udvise meget underlig opførsel (2-300% CPU load over det normale) kort efter kl. 02, og en stop / start af VM'erne hjalp intet. Efter start røg CPU load op på 2-300% igen og maskinens samlede load var også derefter.
Præcis samme opførsel her på Ubuntu 11.10
-
0
-
0
Vi så det også på vores CentOS5 og 6'ere - jeg tror også det er noget der skal holdes øje med i fremtiden.
Jeg må dog sige at jeg er glad for det ikke var 31. dec denne gang...
/Anders
-
0
-
0
Præcis samme opførsel her på Ubuntu 11.10
Også her på Ubuntu kernel 2.6.32-41-server.
Rimelig nasty bug. Gætter på, at mange lige nu sidder og roder med performanceproblemer på java app servers, der ville kunne fikses med ovenstående one-liner.
Red Hat har en beskrivelse af det her, og som altid er der værdifuld info i kommentarsporet:
-
0
-
0
Det undrer mig lidt hvorfor Linux rammes.
Hvordan håndterer den det. Hvis det sker via NTP, så vil den jo blot mikro steppe lidt og så er den potte ude.
-
0
-
0
Det skyldes åbenbart, at Javas System.currentTimeMillis() på linux kalder gettimeofday(). Hvorfor den fremgangsmåde ikke er "leap second safe", kan jeg ikke umiddelbart svare på.
-
0
-
0
Java har generelt et problem, når man sætter tiden (http://stackoverflow.com/questions/9044423/java-scheduler-which-is-compl...).
Jeg tror det er en nedarvning fra POSIX, hvor rigtigt meget i API'et hænger på UTC tiden, og dermed kan rammes af tidshop (se f.eks. http://linux.die.net/man/3/pthread_mutex_timedlock). Enhver erfaren udvikler vil i dag hænge sin kode op på CLOCK_MONOTONIC, ikke CLOCK_REALTIME; men Java er fra før man indførte disse forskellige ure i POSIX.1-2001.
-
0
-
0
Tilføj kommentar
