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

Kommentarer (35)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Knudsen

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
Thomas Knudsen

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
Mikael Boldt

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
Henning Makholm

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
Frithiof Andreas Jensen

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
Glen Madsen

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
Esben Nielsen

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
Kai Birger Nielsen

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
Benny Lyne Amorsen

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
Jens Dueholm Christensen

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
Jens Dueholm Christensen

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
Martin Kofoed

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:

https://access.redhat.com/knowledge/articles/15145

  • 0
  • 0
Esben Nielsen

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
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize