Binnenkort Y2K-trauma op herhaling

C|Net schrijft dat het Y2K-probleem binnenkort op iets kleinere schaal herhaald zal worden. Een paar jaar terug was het probleem dat computers slechts twee cijfers van het jaartal bijhielden en impliciet er '19' voor zetten, met als gevolg dat na 1999 weer 1900 zou komen. Er zijn echter ook Unix-programma's die het aantal seconden vanaf 1970 bijhouden. Op 10 januari 2004 bedraagt dit aantal 2^30 (ruim een miljard, in tegenstelling tot wat er op C|Net genoemd wordt - 2 miljard).

Aangezien het maximale getal dat 30 bits bij kunnen houden 2^30 - 1 is, zouden er na 10 januari 31 bits nodig zijn om het juiste aantal te kunnen onthouden. Sommige systemen gebruiken echter slechts 30 bits. Het gaat voornamelijk om de programmatuur van softwaremaker PTC, die op dit moment druk bezig is met het maken van patches. Unix werkt zelf met 32-bits signed integers, wat inhoudt dat er één bit voor het teken wordt gebruikt en 31 voor het getal. Hier doen de problemen zich dus pas 2^31 seconden na 1970 voor; 19 januari 2038.

Reacties (50)

[Malthus]

Andere jaren die problemen op kunnen leveren zijn:

2040: Originele Apple Macintosh 128K (telt secondes vanaf 1 januari 1904 in 32-bit unsigned integer)

2116: PC's met IBM hardware (telt secondes vanaf 1 januari 1980 in een 32-bit unsigned integer)

2184: Windows NT (telt 100 nanosecondes vanaf 1 januari 1601 in een 64-bit integer)

29940: Apple Mac (telt (secondes?) vanaf 30081 BC in een 64-bit unsigned integer)

[zeekoe]

Je vergeet eentje
Amiga: 19 Januari, 2046, 03:14:07
Die telt ook in 32 bit signed, maar dan vanaf 1978.

[gooddaddy]

Goh, daardoor zullen zeker veel vliegtuigen neerstrorten

[Verwijderd]

wat hebben sommige systemen toch rare beginjaartallen... wat is het nut om al in 30081 voor christus te beginnen met tellen?

[Standeman]

Archivering van museumstukken misschien?? Waarschijnljik wilde ze gewoon 99,9% af vangen qua mogelijkheden!

[Verwijderd]

dan zou ik kiezen voor: sec (6bits):min (6bits):uur(5bits) || dag (5bits)/maand (4bits)/jaar (singed 64-26 bits), dan kan je van 2^38 BC tot (2^38) -1 AD en dat met één 64 bits getal

[Frag_majeuR]

En niet te vergeten: met myriade-probleem, als we straks naar 9 cijfers over moeten, op 31 december 9999.

[Munters]

Hihi, dat voorbeeld heb ik ook eens gebruikt toen een leverancier mij n.a.v. het y2k vertelde dat ze hun software zo aangepast hadden dat er nooit meer een datum probleem zou optreden met hun software.

[Parlor_Inventor]

Dit is lang niet zo belangrijk als y2k.

meer data waarop iets mis *kan* gaan:
http://www.merlyn.demon.co.uk/critdate.htm

met als laatste datum:
2^1E80 approx. - As there are only about 1E80 particles in the observable universe, it has by now become impossible to write the date.

[Verwijderd]

LOL:
Y2.01K. There will be some who have coded only for Years 200#.

Dat is wel erg dom.

Maar met deze lijst erbij kan je ongeveer elke dag wel moord en brand gaan schreeuwen om een nieuw 'post-Y2K' probleem.

[Verwijderd]

waarom ook niet? Het Y2K "probleem" was zeer winstgevend, plots deden alle IT bedrijven ook "Y2K compliancy checks" enzo bij angstige mensen, wat veel opbracht, er was toen ook een bedrijf bij ons op school gekomen die op elke pc een grote gele sticker met "YEAR 2000 PROOF" kwam plakken, nadat ze de datum eens op post 2000 gezet hadden en gekeken of de pc nog opstartte. Zulke dingen dienen gewoon om de mensen bang te maken en er dan geld uit te kloppen.

[Verwijderd]

...dat het Y2K-probleem binnenkort op iets kleinere schaal herhaald zal worden...

Met andere woorden : er zal dus wéér niets gebeuren, maar dan op kleinere schaal.

[plexon]

Jammer dat er nog steeds mensen zijn die denken dat Y2K niets voorstelde. Het is achteraf natuurlijk best makkelijk praten dat er niets is gebeurt. Dat was ook de bedoeling!!!!
Probleem is hierbij dat ALS het fout gaat NIEMAND kan zeggen dat hij of zij het niet had kunnen weten. Als verantwoordelijke bestuurder heb je dan echt iets uit te leggen!!!!

Ik weet zelf een aantal leuke voorbeelden waarbij het best mis had kunnen gaan. Zo bleek bij Schiphol dat de na een Y2K test op de noodbaanverlichting dat de normale verlichting niet meer aanging en dat door eenY2K probleem met plc in het sluizencomplex IJmuiden een sluisdeur waarschijnlijk niet meer automatisch open had gegaan. Dit zijn maar een paar voorbeelden die de pers niet hebben gehaald. De overheid moet hierbij open zijn (terecht) maar bedrijven zullen niet zo te koop hebben gelopen met hun problemen. Niet zo goed voor hun reputatie kijkt me.

Bij het bepalen van de scope van Y2K projecten zijn vaak bewust maar 2 datumproblemen meegenomen (Y2K zelf en het schrikkeljaar 2000) andere datums zoals het unix probleem zijn bewust buiten scope gelaten.

[DaRealRenzel]

offtopic: Op zondag 2 januari 2000 vloog ik voor me werk naar Londen, en toen bleek dat in Amsterdam het hele bagagehandling systeem plat te liggen - ALle bagage moest met de hand 'gehandled' worden, met als resultaat dat mijn koffer naar Karachi gestuurd was... Nooit iets van in de pers vernomen, maar duidelijk dus wel een echte Y2K Bug....

[Verwijderd]

Ik denk dat je een grapje maakt.

Ik heb destijds voor het Y2K verhaal flink wat extra uren gemaakt in 1999, servers upgraden en patchen.

Op 5 januari 2000 kwam iedereen op het werk: "zie je wel, niks aan de hand !"

Beetje moe word ik daarvan

[Jack Flushell]

Het gaat voornamelijk om de programmatuur van softwaremaker PTC, die op dit moment druk bezig is met het maken van patches.

Echt onvoorstelbaar dom vind ik dit. Dit wisten ze al jaaaren en nu nog zijn ze druk bezig... lekker over 10 dagen is het al zo ver.... Je ziet dit toch aankomen??

edit:
Oke 20 dagen dan...(wat ben jij een opletter en een mierenn&^$^%$ zeg ... maar het blijft dom

[MRic3]

lekker over 10 dagen is het al zo ver

ik leestoch echt:

Op 10 januari 2004

Ga jij vanavond vuurwerk afsteken en nieuwjaar vieren dan?

ontopic... ik denk dat ze er nou wel van leren en die andere data zullen wel niet zo belangrijk zijn. Die zijn zo ver weg dat die echt niet meer draaien rond die tijd.

[MBV]

Weet je nog waardoor die fouten erin zijn gekomen? "ach joh, je maken dit programma in 1980, en over 20 jaar hebben ze allang een andere. Doe niet moeilijk, 2 characters is genoeg. Geheugen is nu veel te duur ". Ik hoop dat jij niks programmeert, want stel je voor dat jouw programma bij mijn bank draait, de komende 50 jaar....

[X-G]

Waren ze er in begin 1970 allemaal ervan overtuigt dat de wereld freakin' zou vergaan over een jaar of 30/33????!

Echt altijd die rare problemen

[plexon]

Nee, men was er alleen vanuitgegaan dat het OS niet zo lang onaangepast zou blijven. In die tijd was geheugen nog heel erg duur. En wie wilde er duizenden guldens investeren in een probleem voor over 30 jaar dat waarschijnlijk tussentijds wel zou worden opgelost!!!

[Verwijderd]

Ik zou me voor kunnen stellen, dat bij software met het Y2K probleem, alles nog steeds goed functioneert, doordat bij tijdgebonden acties, ook de Y2K-bug word gemaakt, dat alleen de laatste 2 cijfers van het jaar worden gecontroleerd..
Dus als om "1 januari 00", een actie moet worden uitgevoerd, werkt dat nog steeds.

Ik zou eerder een probleem zien, wanneer het klokje van de eeuw rond is.
Dan zouden in 2060 (geautomatiseerde) conclusies getrokken kunnen worden, uit data die in 1960 is opgeslagen..

Maar tegen die tijd zal er echt allang nieuwe software geschreven zijn..

[MBV]

Stel, mijn oma is in 1900 geboren, opgeslagen als 00. Het is nu 2003, dus ze krijgt volgend jaar een brief dat ze naar de kleuterklas moet.
Ander voorbeeld: Oma is in 35 geboren, en ze komt te overlijden in 03. ze krijgt haar lijfrente of zoiets niet uitgekeerd omdat ze nog niet geboren is.
Ander voorbeeld: 99 is datum onbekend, 98 is binnenkort enz. Dat bedrijf had een milleniumbug in 1997

Zulke stomme fouten komen er in software als de datum niet klopt

[tikimotel]

Waarschuwing voor alle MS-DOS 4.01 gebruikers!

Je raakt al op 1 januari 2084 in de problemen.

Dus wees er op tijd bij en upgraden die boel

[Verwijderd]

Seconden vanaf bepaalde datum bijhouden is op zich best zinvol: wel handig om van een file te weten wanneer die voor het laatst gewijzigd, gelezen, etc is...

Maar wat voor zin het heeft om dit (UNIX) in een signed int op te slaan dat ontgaat me een tikkeltje...

edit:
sorry, verkeerd geplaatst. Was als reactie op kingfinn bedoeld

[Harry_Sack]

dat gaat om de major, minor nummers, die moeten uniek zijn

[Verwijderd]

Met een signed int kan je ook datums van VOOR 1970 weergeven. Dit kan wel eens handig zijn. (geboortedatums bijvoorbeeld)

[Verwijderd]

...echt handig is een einddatum niet, maar het wordt pas vervelend als je het gaat integreren met kritische systemen en dan vergeten met hoe je 't ook alweer hebt geintegreerd. Een kritisch systeem dat het tot 2048 oid zou doen is goed, de controle (kennis) verliezen is het echte probleem, niet de houdbaarheid van een bouwsteen...

[Verwijderd]

Het zal aan mij liggen, maar als je gewoon de software aanpast op het datum gedeelte, dat je bijvoorbeeld gewoon de seconden vanaf 2000 in de berekening gebruikt, heb je het probleem toch zo weer opgelost

[Aesculapius]

Dat kan toch niet? Een Unix timestamp is volgens mij wel redelijk universeel vanaf 1970. Als je dan op een paar systemen die telling aanpast wordt die timestamp in combinatie met andere systemen totaal onbruikbaar, dat lijkt me toch niet de slimste oplossing.
Gewoon de std unix 32 bits signed int's gebruiken, dan kan je weer even vooruit en tegen de tijd dat dat een probleem wordt, wordt het systeem toch allang niet meer gebruikt

[Brahiewahiewa]

Ja, en helemaal bizar dat al die 3400 werknemrs van PTC over deze oplossing heen gekeken hebben, is't nie? Heb je ze al gebeld?