Skal hjelpe IT-avdelingene med å håndtere skuddsekunder

[Harald Brombach (digi.no)]

Skal hjelpe IT-avdelingene med å håndtere skuddsekunder

[rillto]

Lurer på hvorfor skuddsekunder er så mye verre enn skuddår, ulik lengde på måneder osv.

Det korrekte antallet måneder skulle vært 13. Det er 13 månesykluser a 28 dager i naturen. Vår fiksering på å finne midtvinter og midtsommer har rotet kalenderen og tiden skikkelig til for oss.

 

Men skuddsekundene ville vi fremdeles hatt uansett kalenderens utforming.

[qualbeen]

Men skuddsekundene ville vi fremdeles hatt uansett kalenderens utforming.

Korrekt! Og nettopp derfor er skuddsekunder så mye vanskeligere enn å håndtere vår ellers snodige kalender (med skuddår hvert fjerde år, dog ikke hvis årstallet er delelig med 400. Eks.: år 2000.).

 

Kalenderen vår er lett å programmere; den består av et sett faste regler. Så snart alle reglene først er på plass, er det trivielt å håndtere datoer. Heldigvis.

 

Selvfølgelig hadde det vært langt enklere om alle måneder var like lange. Da kunne jo hvem-som-helst gjort utregninger, uten å måtte ta høyde for hvilke måneder man ser på, skuddår, etc. Men men …

 

Skuddsekunder derimot – skjer som du nevner helt uregelmessig. Og er dessverre smertefullt for enkelte IT-systemer.

 

EDIT: Se fasit fra sk0yern rundt skuddår. Jeg blingset litt rundt detaljene.

Endret 5. desember 2016 av qualbeen

[sk0yern]

Korrekt! Og nettopp derfor er skuddsekunder så mye vanskeligere enn å håndtere vår ellers snodige kalender (med skuddår hvert fjerde år, dog ikke hvis årstallet er delelig med 400. Eks.: år 2000.).

 

Nesten, år 2000 var faktisk et skuddår.

Regelen er at det ikke er skuddår dersom året er delelig med 100, men bare dersom det ikke også er delelig med 400 :-)

[G]

@qualbeen:

Hvor tilfeldig skjer skuddsekund?

 

Jeg vet at jorden i solsystemet stadig endrer seg ørlite. Så dersom man f.eks. har satt seg inn i hvordan skuddår fungerer så var det på et gitt tidspunkt det virkelige året (ikke kalenderåret) kanskje definert å være:

 

365 dager, 5 timer, 48 minutter og 40 sekunder, altså nesten 6 timer i overskudd, derav at skuddåret skytes inn nå og da, omtrentlig hvert fjerde år (med visse unntak vil jeg tro). Denne tiden som jeg knotet ned for dere er i stadig endring, og en gang i framtiden så vil den være relativt forskjellig i fra nå/da i fortiden. Det jeg skrev ned var sikkert ikke pinlig nøyaktig den gang heller (da det ble notert ned som en sannhet), da det nok er en del desimaler som kan være vanskelige å gjøre om til fornuftige heltall. Dette grunnlaget som desimaltall endres altså kontinuerlig, og er ingen statisk tallverdi.

 

Til det litt trivielle/morbide:

Har det noen gang dødd noen som en følge av et skuddsekund, eller er dette mest viktig for eksempelvis for aksjemarkedene og andre som har behovet for nøyaktighet?

 

Tidssoner:

Tidssoner er jo også en kunstig lagd greie. Også de definerte tidssoner har rare menneskeskapte konstellasjoner. Og det siste jeg husker om en liten endring der, var at Hugo Chavez endret Venezuela sin deltakelse i tidsoner med 30 minutter for noen år tilbake. Han gjorde vel dette som en ren maktdemonstrasjon, og ikke av særlig praktiske årsaker vel? Ihvertfall ble det for meg som leser oppfattet som en maktdemonstrasjon. Just because I can !!

Endret 5. desember 2016 av G

[Lars Marius Garshol]

> siden hensikten med det hele tross alt er at man skal kunne lese av den samme tiden på ulike steder

 

Bortsett fra, selvfølgelig, at det er en umulig ambisjon, som Google utmerket vel vet. Det vi kaller "samtidig" er bare en illusjon. Einsteins relativitetsteori sier at ulike observatører ikke nødvendigvis vil oppleve de samme hendelsene i samme rekkefølge. Datamaskiner har det samme problemet, og der er det virkelig merkbart. Det er derfor vi har CAP-teoremet, og det er derfor vi trenger kompliserte protokoller som Paxos og Raft for at maskiner skal kunne bli enige om hvilken rekkefølge ting skjedde i.

[G]

Flott Lars Marius Garshol, om man behøver en virkelig vitenskapelig satt opp datamaskin, eller kan dette påvirke så trivielle ting som aksjemarkedet også kanskje?

[qualbeen]

@qualbeen:

Hvor tilfeldig skjer skuddsekund?

 

Jeg vet at jorden i solsystemet stadig endrer seg ørlite. […]

 

Helt tilfeldig er det nok ikke, og vitenskapsmenn (og -damer ;-)) kan sikkert regne seg frem noen år i tid. Noen eksakt formel tviler jeg dog på at foreligger.

 

Det kan nemlig være mange grunner til at tiden Jorda bruker rundt Sola ikke er 100% stabil. Kanskje var Jupiter eller andre tunge planeter i nærheten, og bremset hastigheten vår noe? Kanskje kan planeters fravær eller andre solsystemer påvirke bittebittelitt? 

 

P.t. fyker vi av gårde i over 100 000 km/t. Og særlig mye saktere kan det ikke gå før det blir i overkant hett, men mindre avvik i ene og andre retningen vil det nok alltid forekomme. Og dermed får vi utslag på sekund-nivå. 

 

Avslutningsvis: Et år består av over 31 millioner sekunder. Å måtte justere opp og ned ett fattig sekund, tilsvarer altså mindre enn 1 / 31000000. Eller 3.22e-8. Dette er et ufattelig lite tall. Jeg ville nesten trodd at tiden vi bruker rundt sola varierer med større faktor enn dette lille tallet. Men men – stemmer sikkert? Dette kan jeg egentlig ikke noe særlig om …

 

 

Tidligere skuddsekunder, sakset fra Wikipedia:

• 1. juli 1972
• 1. januar 1973
• 1. januar 1974
• 1. januar 1975
• 1. januar 1976
• 1. januar 1977
• 1. januar 1978
• 1. januar 1979
• 1. januar 1980
• 1. juli 1981
• 1. juli 1982
• 1. juli 1983
• 1. juli 1985
• 1. januar 1988
• 1. januar 1990
• 1. januar 1991
• 1. juli 1992
• 1. juli 1993
• 1. juli 1994
• 1. januar 1996
• 1. juli 1997
• 1. januar 1999
• 1. januar 2006
• 1. januar 2009
• 1. juli 2012
• 1. juli 2015

[Lars!!]

Lurer på hvorfor skuddsekunder er så mye verre enn skuddår, ulik lengde på måneder osv.

 

Skuddår, måneder med ulik lengde og sommertid er konsepter som er lagt oppå tiden som datamaskiner vanligvis jobber med (sekunder eller millisekunder siden 1970-01-01 00:00.00 UTC). Et skuddsekund, derimot, innebærer at selve tiden i datamaskinen justeres et sekund (eller 1000 millisekunder) tilbake. Det er vanlig å anta at tiden kun beveger seg framover, men programmer som gjør denne antagelsen vil ikke takle skuddsekund.

[G]

Går det ikke an å bake det inn i CPU'ene med et instruksjonssett, slik at en kan programmere seg fram til en korreksjon som maskinene aksepterer uten å gå i stå? Et Instruksjonssett knyttet i mot "maskinklokken", slik at det går an å overstyre den.

 

Den overstyrte tiden er den reelle tiden uansett hvordan det forholder seg til den forhistoriske tid. Den der Google tidsutsmørningen kan vel en CPU også kunne gjøre, bare man forteller den hva den må gjøre "bak i kulissene" før den presenterer "maskinklokken" for OS'et.

 

Har ikke "maskinklokken" tradisjonellt ligget i BIOS? Kanskje det er på tide å flytte denne klokken inn i CPU, eller at BIOS kan overstyres av CPU på dette med hva "sanntiden" skal hete/være. Backupmessig så må det vel gå an at "en promille" av kretsene i CPU mottar strøm i fra en ekstern batteribackup.

Endret 6. desember 2016 av G

[Sokkalf™]

CPUen driter i hva klokka er. Den har heller ingen begrep om tiden, annet enn sin egen klokkefrekvens.

 

Problemet er når man får en race condition eller et uhåndert unntak i et program pga. at utvikleren ikke har tatt høyde for det, som Lars!! påpeker over her.

[Emancipate]

De burde latt 1 sekund i datamaskinen ta 2 sekunder i virkeligheten. Ikke stille klokka tilbake.

Endret 6. desember 2016 av Emancipate

[Sokkalf™]

Den stilles vel heller ikke tilbake. Sånn det har vært håndtert i linux har vel vært slik at man har fått et ekstra sekund ved midnatt - 23:59:60 - før klokka ruller over til 0:00:00.

 

Edit: Det sier visst artikkelbildet også

Endret 6. desember 2016 av Sokkalf™

[Emancipate]

At klokka er det samme to ganger er uansett en dagligdags sak, det skjer hver gang PC-klokka går for fort, og så stilles tilbake når tiden synkroniseres. Det er jo en grunn til at man synkroniserer over internett, nemlig at PC-klokka ikke er perfekt presis i seg selv. Så dette må et program kunne takle.