Dette indlæg er alene udtryk for skribentens egen holdning.

Husk: Skudsekund d.30

Af Poul-Henning Kamp15. juni 2012 kl. 09:3135
Artiklen er ældre end 30 dage

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.

Artiklen fortsætter efter annoncen

phk

35 kommentarer.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
32
2. juli 2012 kl. 14:20

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.

33
2. juli 2012 kl. 14:38

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å.

27
1. juli 2012 kl. 16:43

Hov, jeg beklager dobbeltpost - jeg fik timeout på post fra Varnish, og ville egentlig bare have ventet til senere med at poste.

25
1. juli 2012 kl. 12:35

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..

34
2. juli 2012 kl. 16:52

Java har generelt et problem, når man sætter tiden (http://stackoverflow.com/questions/9044423/java-scheduler-which-is-completely-independent-of-system-time-changes).

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.

30
2. juli 2012 kl. 12:19

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

24
1. juli 2012 kl. 12:34

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..

18
17. juni 2012 kl. 22:19

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.

21
18. juni 2012 kl. 17:31

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.

17
17. juni 2012 kl. 14:10

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

16
16. juni 2012 kl. 21:15

Uden den info var jeg kommet for sent på arbejde :-(

19
18. juni 2012 kl. 10:44

Eller var det omvendt - for tidligt ;-)

20
18. juni 2012 kl. 12:46

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

13
15. juni 2012 kl. 19:25

1908 was the longest year ever, but a party is still appropriate. Drink fast! Skål

12
15. juni 2012 kl. 17:01

Skuddag og skudsekund - det bliver et langt år...

11
15. juni 2012 kl. 16:57

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.

7
15. juni 2012 kl. 13:19

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

10
15. juni 2012 kl. 15:49

Så skal vi endnu tidligere op her midt i sommertiden

Nej, tværtimod kan du sove længe

4
15. juni 2012 kl. 13:08

Jeg tænker bare: Hvordan har folk fundet ud af det? :D

6
15. juni 2012 kl. 13:12

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.

http://www.ucolick.org/~sla/leapsecs/

1
15. juni 2012 kl. 09:46

Jeg har så lige læst hvad skudsekund er.. Sikke dog en skævhed! :)

2
15. juni 2012 kl. 12:52

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.

8
15. juni 2012 kl. 13:34

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.

9
15. juni 2012 kl. 15:01

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.

5
15. juni 2012 kl. 13:08

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