BEDRIFTSTEKNOLOGI

Hvis ikke Y2K tok knekken på deg, bare vent til 31.7. 31086

Tusenårsskiftet er passert, og verdens undergang ble en kuriositet. Men faren er ikke over. digi.no gir deg problemkalenderen fra 29.2.2000 via skjebnesvangre 31.7.31086 klokken 02:48:05:47, til året 60056, da 64-bits Win32 ubønnhørlig vil måtte takke av.

Harald BrombachHarald BrombachNyhetsleder
3. jan. 2000 - 11:02

Denne kommentaren gir uttrykk for skribentens meninger.

Selv om nyttårsaften passerte uten at de helt store katastrofene skjedde, er det ennå alt for tidlig å si at hele overgangen til et nytt tusenår gikk tilnærmet smertefritt. Først i dag starter verden opp for fullt igjen, men en kan vel anta at de fleste har testet i hvert fall de viktigste delene av sine datasystemer allerede i helgen.

De fleste feilene digi.no er blitt informert om, er forbundet med forskjellige tjenester på Internett. Det kan nesten virke som om disse tjenestene er blitt sett på som mindre viktige enn de interne systemene hos de aktuelle bedriftene. Feilene er stort sett rimelig uskyldige, men vil nok med tiden være mer irriterende enn morsomme. Blant annet gjelder dette gjesteboken SOL tilbyr selskapets kunder. Datoen på nye innlegg plasseres 1900 år tilbake i tid. (se Gjesteboka til Tor Sparhell).

Millenium-bug hos Fellesdata. Årstallet skulle ha vært 2000, ikke 100. <i>Skjermbilde:  Digi.no-leser</i>
Millenium-bug hos Fellesdata. Årstallet skulle ha vært 2000, ikke 100. Skjermbilde:  Digi.no-leser

Fellesdatas nettbank har også problemer. Bildet til høyre fikk vi fra en leser som prøvde tjenesten i dag tidlig. Som bildet viser er også her datoen satt 1900 år tilbake, det vil si år 100. Systemet har altså trodd at vi har oppholdt oss i år 99 i stedet for år 1999. Tjenesten for øvrig virker som forventet.

Også Microsofts TerraServer-tjeneste er på villspor når det gjelder valg av årstall. 19100 er blitt et vanlig eksempel på hvordan enkelte datasystemer tolker året etter 1999.

Selv om problemene forbundet med tusenårsskiftet ikke blir verre enn de som hittil er blitt oppdaget og varslet, er ikke verdens datasystemer trygge så veldig lang tid framover. Det neste problemet dukker allerede opp om under to måneder.

Normalt er det ikke skuddår året etter et hundreårsskifte. Dette inntreffer kun hvert fjerde år. Det er derfor ikke usannsynlig at en del programvare og systemer ikke tar med i beregningen at år 2000 er et skuddår. Hvor store problemer dette vil medføre, er uklart, men til og med ved vanlige skuddår er det blitt rapportert om dataproblemer tilknyttet datoen 29. februar.

Likevel, hvis en ser tilbake på året som gikk, var det flere slike potensielle dataproblemer som bare forsvant i stillhet. 1. januar 1999 var det fare for at mange kontrakter, poliser og lån ville utløse milleniumfeilen allerede ett år før tiden, fordi disse dokumentene hadde utløpstid den 1. januar 2000.

Den 9. april 1999 ble også ansett som en kritisk dato, da det var den 99 dagen i (19)99. Sammen med 9. september kunne begge disse datoene representert et problem fordi datoene kunne ha blitt representert som 9-9-99 eller 9999, som iblant er blitt brukt som avsluttende kode i forskjellige datastrukturer. Ingen av disse datoene medførte problemer av betydning.

Et tilsvarende problem, dog ikke forbundet med noen bestemt dato, var at aksjeindeksen Dow Jones Industrial Average passerte 10.000 poeng i 1999. Noen dataeksperter mente at dataprogrammer kunne få problemer med å håndtere dette tallet når det gikk fra fire til fem siffer. Enten ble det svært få problemer, eller så ble det gjort en kjempejobb i å dekke over problemene.

Derfor er det mest for kuriositets skyld at vi gjengir følgende oversikt over potensielle dataproblemer som kan dukke opp i årene som kommer. Det kan jo være greit å forberede seg litt.

10. oktober 2000 Første dato i det nye tusenåret med åtte siffer
1. januar 2002 Burroughs Unisys A Serie-systemer kan få datofeil
2005 Noen virkelig gamle Unix-utgaver kan komme til å gå av pensjon dette året (for eksempel 16-bits BSD)
1. januar 2020 Systemer som bruker 1920 som startår vil feile
1. januar 2020 Brukere av Mac OS System 6.0.4+ vil ikke kunne stille inn datoen ved hjelp av kontrollpanelet for dato og tid.
23. desember Verdens undergang, ifølge kalenderen til Maya-folket
1. januar 2030 Systemer som bruker 1930 som startår vil feile
6. februar 2036 2^32 sekunder siden 1. januar 1900
19. januar 2038 Unix: 2^31 sekunder siden 1. januar 1970
6. februar 2040 Klokken 06:28:126 vil gamle Macintosh-maskiner få en overflytsfeil i antall sekunder siden 1. januar 1904
17. september IBM 370 TOD-klokken får overflytsfeil
1. januar 2044 MS-DOS: 2^6 år siden 1980. Kan få negativt resultat i spesielle variabler
1. januar 2046 Amiga får datofeil
8. juni 2046 Noen Unix-passord får feil alder. 64^2 uker siden 1970
31. desember 2049 Microsoft Project 95 går tom for datoer
31. desember 2078 Microsoft Excel 7.0 går tom for datoer
6. juni 2079 2^16 dager siden 1. januar 1900
1. januar Mange brikkesett går tom for datoer. DIR-kommandoen i MS-DOS gjengir årstallet i fildatoer i årene mellom 2100 og 2107 som 99
7. februar 2106 Unix: 2^32 sekunder siden 1. januar 1970. Tiden tar slutt klokken 06:28:16
28. november 2738 Dag nummer én million av vår tidsregning (omtrent)
28. november 4338 Cobol-85 heltallsdag 1.000.000 passerer seks siffer
1. januar 10000 Første gang fem siffer i årstall.
1. januar 19602 Microsoft Windows NT File System (NTFS) feiler
29940 64-bits tiden i Macintosh-maskiner feiler
31. juli 31086 Den interne tiden i Digital Equipment VMS feiler klokken 02:48:05:47
60056 Win32 64-bits tid feiler

Jeg tror likevel at vi kan ta det forholdsvis rolig når det gjelder datoproblemer de nærmeste årene.

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.