Most recent comments
2021 in Books -- a Miscellany
Are, 2 years, 11 months
Moldejazz 2018
Camilla, 5 years, 4 months
Romjulen 2018
Camilla, 5 years, 11 months
Liveblogg nyttårsaften 2017
Tor, 6 years, 11 months
Selvbygger
Camilla, 1 month, 4 weeks
Bekjempelse av skadedyr II
Camilla, 11 months
Kort hår
Tor, 3 years, 11 months
Ravelry
Camilla, 3 years, 6 months
Melody Gardot
Camilla, 5 years, 5 months
Den årlige påske-kommentaren
Tor, 5 years, 8 months
50 book challenge
Camilla, 11 months, 3 weeks
Controls
Register
Archive
+ 2004
+ 2005
+ 2006
+ 2007
+ 2008
+ 2009
+ 2010
+ 2011
+ 2012
+ 2013
+ 2014
+ 2015
+ 2016
+ 2017
+ 2018
+ 2019
+ 2020
+ 2021
+ 2022
+ 2023
+ 2024

UNIX-tid

I gårsdagens post kommenterte Anders at det var litt merkelig at 1970 later til å være default når det gjelder årstall på datamaskiner. I dag tenkte jeg derfor å utdype litt omkring dette, og dermed kommer vi også inn på Y2K38-problemet.

Det har seg nemlig slik at man måtte finne på et eller annet system for å passe på tiden, og da var det sikkert en tidlig nerd som tenkte «La oss telle antall sekunder siden 1.1.1970». Det virket antagelig som en god idé. Ettersom dette skjedde etter 1970 virket det som et trygt valg. Hvis man skulle tatt utgangspunkt i den vanlige tidsregningen ville det dessuten blitt et voldsomt stort tall. Videre tenkte denne nerden at denne informasjonen må jo lagres i noe, og så satt han av 32 bits til tiden, og så sa han seg fornøyd og gikk og tok kaffepause.

Den interne tiden til en maskin måles altså i antall sekunder siden 1.1.1970, og dette kalles UNIX-tid. Og slik har det seg at når klokkebatteriet svikter og telleren begynner på null, så tror maskinen at det er 1970. For de som er skikkelig interressert i dette kan det også være verd å nevne at UNIX-tid ikke teller skuddsekunder.

Og hva er så egentlig et skuddsekund? Jo, nå skal dere høre. Jorden er jo en diger klump med stein med en flytenden kjerne, så det er jo ikke rimelig å forvente at den skal rotere nøyaktig like fort hele tiden. Stort sett vil jorden rotere litt langsommere for hvert år, men hvor mye vil variere. Et jorddøgn, altså den tiden jorden bruker på å rotere en runde i forhold til solen, vil altså være litt forskjellig fra 86400 sekunder. Hvis man ignorerte dette problemet fullstendig ville på lang sikt døgnet bli snudd, og det er ikke noe gunstig. Derfor legger man til et sekund i ny og ne, for å holde sol-tid og UTC innenfor et sekund av hverandre. Dette skjer litt under en gang i året, og later til å være noe som foregår litt i kulissene. Jeg har i alle fall aldri tenkt over at det har skjedd.

Men jo, tilbake til UNIX-tid. Som jeg sa, tiden blir lagret i 32 bits. Det betyr at nar det har gått 2^32 sekunder siden 1.1.1970 vil tids-telleren ha nådd maks, og formodentlig begynne på null igjen, noe som kan skape alt mulig rart av problemer. Dette vil skje i januar 2038. Nå blir det nok ikke noe armageddon denne gangen heller, da det neppe kommer til å være så mange 32-bits maskiner igjen i 2038, og av en eller annen grunn later det til at man bruker like mange bits til å lagre tid som det prosessoren "er". Ikke spør meg hvorfor.

I følge Ben, en venn av Tim, finnes det imidlertid en del spesialiserte dingser, for eksempel på sykehus og slikt, som kommer som en ferdig pakke med god, gammeldags 32-bits prosessor, og disse maskinene kan ha ganske lang levetid, så lang at noen av dem faktisk kan være i drift fortsatt i 2038. Så om du havner på sykehus mot slutten av 2037, husk å sjekke at respiratoren din kjører 64-bits Vista. Eller aller helst OS X.

-Tor Nordam

Comments

Are,  02.03.08 04:02

Unix-tid er igrunn en litt koselig greie. Det kan jo også nevnes (og det har vel vært på bane tidligere) at svært mange har bursdag 1.1.1970 i databasen over brukere her på stedet - fordi jeg og Anders var litt sløve og lot datoen defaulte til starten på unix-tid istedetfor null når folk ikke fylte inn noe. Om jeg ikke husker helt feil.
Tor,  20.02.11 16:35

Y2K38-problemet blekner i grunnen i forhold til Y2K90-problemet, som går ut på hvilken filendelse vi skal bruke på fortran-kildefilene hvis det kommer en ny fortran-standard i 2090. f90 er jo allerede i bruk til fortran90, og jeg regner det som mye mer sannsynlig at det fortsatt vil finnes en eller annen gal professor som bruker fortran 90 i 2090 enn at det fortsatt vil finnes en 32bits-maskin i 2038.
Category
Technology
Tags
unix-tid
Y2K38
Views
4224