De Unix-tijdwaarde wordt vastgesteld op basis van hoeveel seconden zijn gepasseerd sinds een bepaald moment. De verwijzingstijd - ook wel de Unix-epoch - is gekozen door Unix-grondlegger Dennis Ritchie. Unix bestond toen al een tijdje, maar de 1/60ste seconde die oorspronkelijk werd gebruikt, zorgde te snel voor tijdbugs. Een nieuw systeem werd in elkaar gezet waarbij seconden worden weggeschreven in een 32 bit-waarde.
Secondenteller als klok
Het tijdstempel van Unix-systemen is dus in feite een teller die kijkt naar het aantal seconden dat is verstreken sinds de verwijzingstijd. Ritchie stelde 'nul' op 0.00 uur op 1 januari 1970 (grappig genoeg een jaar eerder dan de oude epoch, die nog uitging van 1971). De datum en tijd worden bepaald naar aanleiding van het aantal verstreken seconden dat de teller weergeeft, minus de schrikkelseconden. Vanmiddag om drie uur staat die teller op 1.497.531.600 seconden.
Deze 32 bit-versie van de teller levert op den duur een probleem op. Omdat de binaire waarde van de klokfunctie een lengte van 32 bit heeft (waarvan één tekenbit, zodat Unix-systemen de teller negatief kunnen inzetten om de pakweg zeventig jaar vóór 1970 te kunnen gebruiken), stuit de secondenteller op den duur op een overloopprobleem. Op een dag wordt namelijk de maximale grootte van de 32 bit integer bereikt.
Back to the future
Om precies te zijn gebeurt dat bij de binaire waarde van 2.147.483.647 seconden. Op dat moment is het aantal mogelijke bitjes gebruikt en slaat de klokwaarde om naar een negatieve maximale waarde. De software trekt daarmee de waarde feitelijk af van de oorspronkelijke verwijzingstijd in 1970. De klok stelt zich zo in op 13 december 1901.
Die hoogste waarde van de integer van 32 bit wordt op dinsdag 19 januari 2038 bereikt. Daarom wordt dit issue ook vaak de Y2038 Bug genoemd. Het doet een beetje denken aan de Y2K Bug (wat wij dan de millenniumbug noemden) in de zin dat het om een niet meer kloppende computerklok gaat die terugspringt naar het begin van de twintigste eeuw, maar daar houdt de vergelijking verder op.
Herinnert u zich deze nog?
Het duurt nog bijna twintig jaar voor we hier tegenaan lopen. Angezien er de laatste jaren al updates uitrollen om de Unix Millennium Bug aan te pakken, en hardware en software al jaren overstapt op 64 bit, zou je verwachten dat dit nauwelijks een probleem gaat worden. In 2038 zal toch alles wel 64 bit zijn?
Dat valt nog te bezien. Her en der draaien zelfs nog legacy 16-bit-applicaties en menig 32-bit-applicatie van dit moment spreekt nog 16 bit-componenten aan. Hetzelfde basisprobleem zie je ook terug in 64 bit-software die 32 bit-componenten aanspreekt. Is dat verdwenen tegen 2038? We durven wel te wedden dat over drie jaar hier en daar wat heavy wizardry omvalt omdat stukken die in 1976 zijn geklopt door een inmiddels verdwenen programmeur niet meer functioneert na migratie naar 32 of 64 bit.
Met overstap op 64 bit is het probleem in ieder geval grondig genoeg aangepakt. Met een 64-bit lengte wordt de tijdspanne uitgerekt van 1 januari 1970 tot zondag 4 december 292.277.026.596 en mocht de mensheid dan nog bestaan, zijn we tegen die tijd vast overgestapt op 64 bit.
De Millennium bug was (natuurlijk weer) een windows probleem waar organisaties echt last van hebben gehad en heeft helemaal niets met UNIX te maken.
Blijf lekker tellen Webwereld. Ik heb een naar voorgevoel dat jullie de tel onderweg kwijtraken
Verder met Bassman eens. Kletsverhaal. Blijkbaar was UNIX aan de beurt, gezien de header.
Wat is dit voor een kletsverhaal mensen? Het maakt helemaal niet uit of er een 16-bit systeem gebruikt wordt, zolang de klok maar netjes wordt bijgehouden. Er is werkelijk geen enkele relatie tussen de woordlengte van een CPU en de manier waarop de klok wordt bijgehouden. Voorbeeldje: het 16-bit Amiga-platform heeft een klok die sterk lijkt op de UNIX-klok, al heeft Commodore de epoch in 1978 geplaats in plaats van 1970 en is het een unsigned 32-bit waarde. Gevolg daarvan is dat weliswaar hetzelfde probleem speelt, maar wel pas in februari van 2114. Er zijn nog wel de nodige andere issues in het Amiga-platform die eerder voor problemen zorgen (en gezorgd hebben, maar toen was CBM al failliet), maar een 16-bit platform kan dus keurig 32-bit tijd bijhouden.
Alle op dit moment gangbare UNIX-varianten hebben hun zaakjes inmiddels op orde en slaan de tijd op in een 64-bit waarde. Het probleem doet zich voor bij systemen die nu al legacy zijn en niet aangepast kunnen worden. Moeten we echt medelijden hebben met organisaties die dergelijke systemen over 21 jaar nog altijd niet hebben vervangen?
Enerzijds heb je gelijk, maar er zijn voldoende mensen, die denken dat ze kunnen programmeren, die nog steeds "long time;" gebruiken ipv. "time_t time;" oid. want dan hoef je niet uit te zoeken welke #include je nodig hebt..... De mens blijft lui.
Dus OS en diverse system libraries ben ik niet bang voor, maar usermode code...?
Usermode code die niet het OS gebruikt om de tijd bij te houden is broken by design.. geen medelijden mee. Wie het niet lukt om binnen nu en 20 jaar een testlab op te bouwen met een klok die handmatig 21 jaar vooruit is gezet, verdient stomweg niet beter.
Reageer
Preview