![\"Unix](\"\/wp-content\/uploads\/2020\/01\/1b3a3bdeb0400f3b34d5cd6964a48010.jpg\")
<\/p>\n2020 var bem\u00e6rkelsesv\u00e6rdig for Unix: lige i starten af \u00e5ret fyldte det originale operativsystem 50 \u00e5r. Unix-tiden, ogs\u00e5 kendt som «epoke datoer», — er antallet af sekunder, der er g\u00e5et siden den 1. januar 1970. Men hvad bekymrer kerneludviklerne i forbindelse med Unix\u2019 halvhundrede jubil\u00e6um?<\/p>\n
<\/p>\n
Selvom nogle af de tidlige Unix-udviklinger forudg\u00e5r den officielle begyndelse af sin «epoke», forbliver den 1. januar 1970 nulpunktet i tiden for POSIX. Derfor, med begyndelsen den 1. januar 2020, fyldte platformen officielt pr\u00e6cis 50 \u00e5r.<\/p>\n
Tid <\/strong>Unix i menneskelig tid<\/strong><\/p>\n Set i menneskelig tid er 50 \u00e5r — en lang periode. Set i Unix-tiden er der ikke noget s\u00e6rligt ved 50 \u00e5r, og 43 \u00e5r ville v\u00e6re lige s\u00e5 betydningsfulde. Unix-systemer (herunder Linux) gemmer dato- og tidsv\u00e6rdier som antallet af sekunder, der er g\u00e5et siden 1970-01-01 00:00:00 UTC, med en optegnelse i 32 bit. For at bestemme, hvor mange sekunder der er g\u00e5et siden det tidspunkt, og dermed den nuv\u00e6rende Unix-tid, kan man udf\u00f8re kommandoen:<\/p>\n $ date +%s<\/p>\n 1576883876<\/p>\n Argumentet %s efter date-kommandoen angiver visningen af den nuv\u00e6rende dato og tid som antallet af sekunder siden starten af 1970-01-01.<\/p>\n Hvilken maksimumsdato kan Unix-systemer gemme? <\/strong>Unix?<\/strong><\/p>\n For at forst\u00e5, hvor meget tid en Unix-system kan rumme, skal man vurdere kapaciteten af et 32-bit felt. Dette kan beregnes s\u00e5ledes:<\/p>\n $ echo ‘2^32’ | bc<\/p>\n 4294967296<\/p>\n Men da Unix foruds\u00e6tter gemning af negative tal, reserveres et bit til tegnet, hvilket reducerer tidsv\u00e6rdien til:<\/p>\n $ echo ‘2^31’ | bc<\/p>\n 2147483648<\/p>\n Og da Unix-nummereringen starter fra 0, betyder det, at vi har 2 147 483 648 v\u00e6rdier, men den st\u00f8rste er 2 147 483 647 — v\u00e6rdien af dato og tid i Unix kan ikke overstige dette tal. Ligesom en bils kilometert\u00e6ller ikke kan vise mere end 999 999 kilometer — tilf\u00f8j 1, og v\u00e6rdien nulstilles.<\/p>\n Hvor lang tid varer et \u00e5r i sekunder?<\/strong><\/p>\n Antallet af sekunder i et \u00e5r kan beregnes s\u00e5ledes:<\/p>\n $ expr 24 * 60 * 60 * 365<\/p>\n 31536000<\/p>\n I et skud\u00e5r tilf\u00f8jes en ekstra dag:<\/p>\n $ expr 24 * 60 * 60 * 366<\/p>\n 31622400<\/p>\n Hvordan viser Unix sin 50. f\u00f8dselsdag?<\/strong><\/p>\n 1. januar 2020 kl. 00:00 vil have tiden 1577836800. Beregningen bliver lidt mere kompliceret, da man skal tage h\u00f8jde for skud\u00e5r. Siden Unix-epokens begyndelse har der v\u00e6ret 12 s\u00e5danne \u00e5r, fra 1972 og frem til 2016. Det vil sige, at der er g\u00e5et 38 almindelige \u00e5r.<\/p>\n S\u00e5dan ser expr-kommandoen ud for at t\u00e6lle sekunderne der er g\u00e5et i de sidste 50 \u00e5r:<\/p>\n $ expr 24 * 60 * 60 * 365 * 38 + 24 * 60 * 60 * 366 * 12<\/p>\n 1577836800<\/p>\n Eller s\u00e5dan her, under hensyntagen til de tidligere foretagne beregninger:<\/p>\n $ expr 31536000 * 38 + 31622400 * 12<\/p>\n 1577836800<\/p>\n Denne m\u00e5de at registrere tid p\u00e5 gjorde Unix-systemer uf\u00f8lsomme over for Y2K-problemet, som bekymrede folk sidst i 1999 om, at overgangen til \u00e5r 2000 kunne skade computersystemerne. Der viste sig at v\u00e6re langt f\u00e6rre vanskeligheder end forventet. Faktisk var det kun applikationer, der registrerede \u00e5r i to-cifret format, der stod over for nulstilling af datoer. Mange udviklere har udf\u00f8rt ekstra arbejde for at sikre, at deres applikationer ikke vil blive ramt af Y2K-problemet.<\/p>\n Hvorn\u00e5r <\/strong>vil Unix m\u00f8de problemer?<\/strong><\/p>\n Lignende vanskeligheder venter ikke Unix-systemer f\u00f8r i 2038, n\u00e5r datoer gemt i det ovenfor n\u00e6vnte format overstiger 32-bit rum. Der er stadig 18 \u00e5r tilbage, men kerneudviklere arbejder allerede p\u00e5 at undg\u00e5 de kommende nedbrud.<\/p>\n Problemet i 2038 omtales nogle gange som Y2K38-problemet. Hvis det ikke bliver l\u00f8st inden tirsdag den 19. januar 2038, kan systemerne efter denne dato tro, at det er \u00e5ret 1901. En af m\u00e5derne at l\u00f8se dette problem p\u00e5 er at skifte til en 64-bit repr\u00e6sentation af dato- og tidsinformationen. Nogle mener, at dette ogs\u00e5 vil v\u00e6re meget mere kompliceret, end det ser ud til.<\/p>\n![\"Unix](\"\/wp-content\/uploads\/2020\/01\/aba69e769edb987923b060b6e32f9a00.jpg\")
<\/p>\n![\"Unix](\"\/wp-content\/uploads\/2020\/01\/a720be1bfca58df09540785bf66f556d.jpg\")
<\/p>\n