Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Twintig jaar oude millenniumbug sloeg op 1 januari opnieuw toe

Toen Tweakers slechts twee jaar oud was, vond een van de grootste computercrises ooit plaats: de beruchte millenniumbug. Door hard werk van duizenden programmeurs wereldwijd bleef de voorspelde catastrofe uit, maar niet helemaal: zelfs in 2020 hebben we er nog weleens last van.

Wie dacht dat de millenniumbug inmiddels wel was uitgeroeid, heeft het helaas mis. Op 1 januari van dit jaar kwamen er verschillende incidenten voor waarbij de kwetsbaarheid weer de kop op stak, blijkt nu. Zo werkten deze week veel parkeermeters in New York niet meer met creditcards door een softwarefout. De transportafdeling van de gemeente moet daarom 14.000 parkeermeters in de stad handmatig herstellen. Inmiddels is een groot deel ervan hersteld. De bug werd door de stad 'Y2K2X' genoemd. Ook het metronetwerk in Hamburg leek getroffen te zijn door de inmiddels twintig jaar oude bug.

Oudere tweakers kennen de horrorverhalen rondom de millenniumwisseling waarschijnlijk nog wel. Computers zouden zijn geprogrammeerd tot aan het jaar '99, maar geprogrammeerde jaren zouden op 1 januari van de nieuwe eeuw terugvallen naar '00 en daar zouden systemen van op hol slaan. Er was angst dat winkels niet meer bevoorraad zouden worden, vliegtuigen uit de lucht zouden vallen en de economie stil zou vallen.

Gelukkig bleef de grootste ellende uit, met name omdat duizenden programmeurs wereldwijd minutieus door code heen gingen om jaartallen te vervangen en errors op te lossen. Precies daar ontstond het probleem waar systemen nu, twintig jaar later, weer last van hebben. De meeste experts vermoeden dat veel programmeurs in 1999 de jaartallen lieten doortellen tot '20, in plaats van tot 2099 of nog langer. Waarschijnlijk gebeurde dat in de veronderstelling dat de software die zij destijds schreven tegen 2020 wel zou zijn uitgefaseerd, maar oude apparaten zoals parkeermeters blijken weerbarstiger dan gedacht. Zo blijft de millenniumbug programmeurs ook nu nog achtervolgen. Op naar 2099!

Door Tijs Hofmans

Redacteur privacy & security

09-01-2020 • 09:43

269 Linkedin Google+

Reacties (269)

Wijzig sortering
Als men toch bezig is, los dan ook meteen het 2038 probleem op. Dat is nog maar 18 jaar weg.
Het probleem wat we 19-01-2038 tegen komen is niet het gevolg van luiheid, maar een daadwerkelijke technische beperking van die tijd. Hebben de developers het die tijd een keer goed geimplementeerd door timestamps te gebruiken in plaats van een verkorte notatie van het jaar, is het gebruikte veldtype niet toereikend...

Int32 is maximaal 2147483647
Int64 is maximaal 9223372036854775807, daar kunnen we nog wel wat jaren mee doortellen!
Ik mag verwachten dat een timestamp in een UInt32 wordt opgeslagen, want een computer zal geen timestamps bijhouden van dingen die in het verleden zijn gebeurd (voor 1 januari 1970 in dit geval dus).

Als het wel een Int32 is dan krijgen we bij de wraparound het probleem dat het jaartal ineens terug springt naar 1902.
Ik mag verwachten dat een timestamp in een UInt32 wordt opgeslagen, want een computer zal geen timestamps bijhouden van dingen die in het verleden zijn gebeurd (voor 1 januari 1970 in dit geval dus).
Foute verwachting:
The Year 2038 problem (also called Y2038 or Unix Y2K) relates to representing time in many digital systems as the number of seconds passed since 00:00:00 UTC on 1 January 1970 and storing it as a signed 32-bit integer.
De reden daarvoor is simpel: soms wil men je ook met datums en tijden werken van voor 1970.
Nee, dit is niet de reden.

De voornaamste reden is dat unsiged-integer arithmetic, oftewel, rekenen met getallen zonder positief/negatief indicatie erg vervelend is.

Als A en B tijdpunten zijn, met B na A, en je wilt het tijdpunt B van A aftrekken, dan heb je negatieve getallen nodig om tot een zinvolle uitkomst te komen.

Als je geen negatieve getallen ondersteunt heb je te maken met zogenaamd wrap-around, het antwoord wordt dan het grootst mogelijke getal (zeg 2^32-1) minus het beoogde antwoord.

[Reactie gewijzigd door unglaublich op 9 januari 2020 22:02]

Klinkt logisch, maar klopt niet. CPU's hebben gewoon een substract instructie. Daarmee kun je twee positive intergers van elkaar aftrekken, zonder er eerst een van een min te voorzien.

Daarnaast kijk je bijvoorbeeld naar Python, daarin bestaat geen timestamp voor het jaar 1960; ook op die manier geen negatieve timestamp dus.

[Reactie gewijzigd door djwice op 9 januari 2020 21:04]

Wat klopt niet? De substractie instructie staat los van dit probleem.

In x86 assembly, met de `sub` instructie.
mov eax, 10
sub eax, 20


equivalent
uint8_t a = 10;
uint8_t b = 20;
uint8_t c = a - b; // geeft 246

[Reactie gewijzigd door unglaublich op 9 januari 2020 22:02]

Oh had het verkeerd om gelezen. Maar met timestamps krijg je geen resultaat als je onder 0 komt. Dus vermoed dat bij sub wordt gekeken met cmp of resultaat kleiner is dan A en kleiner is dan B.
Maar het gaat niet om de CPU, het gaat om het typesysteem in C. Het type van een timestamp is een 'time_t', zoals gedefinieerd in <time.h>. Als die unsigned zou zijn, dan is het verschil tussen 2 timestamps ook automatisch unsigned, en dat wil je niet.

[Reactie gewijzigd door .oisyn op 10 januari 2020 22:02]

De reden daarvoor is simpel: soms wil men je ook met datums en tijden werken van voor 1970.
Maar dat is een wazige redenering. Als je dingen in het verleden op wil kunnen slaan, dan heb je over het algemeen dus sowieso al te maken met een veel groter bereik dan alleen alles vanaf 1902 en dus is een 32-bits timestamp niet geschikt (een 64-bits signed timestamp gaat dan iig nog voorbij de big bang, dus dat lijkt me op zich wel afdoende :P). Bovendien is een resolutie van een seconde dan vaak ook niet meer zo belangrijk, dan is een ander datatype geschikter.

[Reactie gewijzigd door .oisyn op 9 januari 2020 12:55]

Over het algemeen ga je geen Unix timestamps gebruiken om bijvoorbeeld datums op te slaan in een database met bijvoorbeeld persoonsgegevens. Maar toen het systeem werd uitgevonden was er wel de noodzaak om te communiceren en te converteren met computersystemen van voor 1970 en had je dus ook negatieve timestamps nodig.
Soms heeft het idee van een unix_datestamp (naast de unix_timestamp) zo zijn charmes.
De reden daarvoor is simpel: soms wil men je ook met datums en tijden werken van voor 1970.
Hoe vaak komt het voor dat je een moment van vóór 1970 tot op de seconde precies zou willen aanduiden? Vaak zijn dan jaar, maand, dag (en misschien nog uren:minuten) al meer dan genoeg.
Niet vaak, maar om daar nou een apart systeem voor te maken als je al een "werkend" iets hebt waar het mee kan...
Iets dat maar tot 1902 gaat vind ik niet echt classificeren als "werkend" :). De set van situaties waarbij je dingen van voor 1970 maar wel na 1902 op wil slaan lijkt me behoorlijk klein.

[Reactie gewijzigd door .oisyn op 9 januari 2020 12:57]

De logs van de maanlanding?
Geboortedata van personen boven de 50?
Want je wil echt weten op welke seconde iemand geboren is? Als we dat al kunnen bepalen?

En met historische data (zoals de maanlanding) heeft het ook geen zin om het in 'seconden sinds epoch' op te slaan, de enige reden waarom je dat zou willen doen, is als je ermee wil rekenen.
Weer data lijkt me dit wel een nuttige toepassing
Dus profielen van mensen met een geboortedatum van vóór 1970 zullen we voortaan maar gewoon negeren/verwijderen? Uiteraard worden er wel timestamps bijgehouden van dingen die voor 1-1-1970 zijn gebeurd.
Dus profielen van mensen met een geboortedatum van vóór 1970 zullen we voortaan maar gewoon negeren/verwijderen?
Waarom zou je in een profiel van iemand precies willen bijhouden op welke seconde hij/zij precies is geboren? Dan is alleen een datum meer dan genoeg (en veel systemen zetten dan het tijdstip gewoon default op middernacht).
Je denkt te veel in jaren/dagen/uren/seconden (ik sla er voor het gemak een paar over).
Als je dit systeem gebruikt (wat niet zo heel gek is om te doen) dan bestaan er alleen maar seconden.

Het verschil uitrekenen tussen 2 Unix timestamps supermakkelijk.
Het verschil uitrekenen tussen 2 data (zelfs zonder tijdstip) is veel lastiger; niet alleen de maanden zijn niet even lang, 1 maand is soms langer dan anders en daardoor zijn zelfs niet alle jaren even lang.
Dat is geen antwoord op de vraag. Je kunt ook gewoon de dagen tellen, dan is je bereik veel groter. Maar hoe dan ook, gebruik gewoon het juiste datatype, waarom het wiel opnieuw uitvinden. De unix timestamp is precies voor dat doel, om dingen te timestampen. Daarmee geef je nog geen dag in het verleden aan, daarvoor zijn er meestal geschiktere date types die wel gewoon een stuk verder teruggaan. En die laten ook toe om gewoon gemakkelijk het verschil uit te rekenen.

Overigens klopt dat verschil niet bij unix timestamps, door de schrikkelseconden (die niet gerepresenteerd kunnnen worden met een unix timestamp)

[Reactie gewijzigd door .oisyn op 9 januari 2020 13:02]

Een UNIX timestamp zijn het aantal seconden sinds de EPOCH. Schrikkelseconden zijn alleen van belang als je deze in een datum/tijd gaat omzetten. Het verschil tussen twee timestamps bereken je zonder iets te hoeven weten hoe een datum eruit ziet.
Een UNIX timestamp zijn het aantal seconden sinds de EPOCH
Fout. Een schrikkelseconde zit niet in een unix timestamp, dus het is niet simpelweg het aantal seconden vanaf een bepaalde tijd. De laatste schrikkelseconde was op 31-12-2016 23:59:60. De seconde ervoor (dus 23:59:59) heeft de timestamp 1483228799. Die erna (dus 0:00:00 op 1 jan 2017) heeft 1483228800. Het verschil tussen die twee momenten is toch echt 2 seconden in echte tijd, maar het verschil in timestamp-waarde is slechts 1.

Anders gezegd, er zijn sinds 1972 in totaal 27 schrikkelsecondes geintroduceerd. Dus het verschil tussen 1-01-2017 en 1-1-1970 UTC is niet 1483228800 seconden, zoals de unix timestamp zou doen vermoeden, maar 1483228827 seconden.

[Reactie gewijzigd door .oisyn op 9 januari 2020 13:58]

Het zijn het aantal seconden, als ware het een stopwatch die men toen gestart had. Ongeacht onze pogingen onze onnauwkeurige kalenders recht te trekken.
Het zijn het aantal seconden, als ware het een stopwatch die men toen gestart had. Ongeacht onze pogingen onze onnauwkeurige kalenders recht te trekken.
Juist niet dus 8)7. Het aantal seconden dat is verstreken is namelijk *inclusief* de schrikkelseconden, maar die zijn niet meegeteld. Een stopwatch zou op 1-1-2017 0:00:00 gewoon 1483228827 aangegeven hebben, en dat komt dus niet overeen met de timestamp op dat moment.

[Reactie gewijzigd door .oisyn op 10 januari 2020 11:07]

De stopwatch zou 0 aangeven op 1-1-1970 0:00:00 en juist gestart worden in mijn voorbeeld. (Jij zit in 2017)
Maar je hebt gelijk dat schrikkelseconden niet eenvoudig worden genegeerd. Er zijn zelfs verschillende manieren om deze te compenseren/mappen lees ik, waarbij je ofwel een timestamp kunt hebben die ambigu is of die helemaal niet bestaat.
Klonk zo simpel;
"Leap seconds are ignored, with a leap second having the same Unix time as the second before it, and every day is treated as if it contains exactly 86400 seconds."

bron: https://en.wikipedia.org/wiki/Unix_time
De stopwatch zou 0 aangeven op 1-1-1970 0:00:00
Sorry, ik bedoelde natuurlijk 1-1-2017 :)
Sterker nog: zowel de 59:60 als de 00:00 hebben dezelfde waarde in Unix time.

Ik vraag me overigens af hoeveel systemen er correct een verschil van 2 seconden opleveren als je het verschil tussen 59:59 en 00:00 berekent. Timeanddate.com vindt iig 1 seconde:
From: Thursday, 31 December 1998, 23:59:59
To: Friday, 1 January 1999, 00:00:00

Result: 0 hours, 0 minutes and 1 second
(En ja, het is mogelijk dat timeanddate.com gebruik maakt van Unix time :+ )

[Reactie gewijzigd door Blackbird-ce op 9 januari 2020 20:15]

Het verschil uitrekenen tussen 2 Unix timestamps supermakkelijk.

Vertel mij dan maar of ik vandaag jarig ben.
Het is nu 1578664020 unix time.
Ik ben geboren op 447678180 unix time.

Hiervoor heb je dus datatypes zoals .oisyn en Stoney3k indirect al aangeven, en elk datatype heeft zijn eigen range en granulariteit/accuracy. Zonder de wens voor abstractie zouden we nu allemaal nog platte C code schrijven op basis van enkel integers.
Nee, maar daar zijn de timestamps ook niet voor bedoeld. Deze zijn ontworpen als een vorm van lineaire systeemtijd, niet als datum/tijdsopslag in een database.
Tegenwoordig mag je eerder verwachten dat de meeste systemen een timestamp in ISO8601 zullen aanleveren, in plaats van een integer van welke lengte dan ook.
Dat is geen timestamp. De meeste systemen werken met een timestamp omdat hier gemakkelijk mee te rekenen is.
Dat zou ideaal zijn.., maar dat komt in de werkelijke wereld helaas niet vaak voor.
Ik mag verwachten dat een timestamp in een UInt32 wordt opgeslagen, want een computer zal geen timestamps bijhouden van dingen die in het verleden zijn gebeurd (voor 1 januari 1970 in dit geval dus).

Als het wel een Int32 is dan krijgen we bij de wraparound het probleem dat het jaartal ineens terug springt naar 1902.
uints zijn niet handig om te rekenen. Als je twee timestamps van elkaar wilt aftrekken om bv. een delta te bepalen dan wil je met signed getallen werken.
Het probleem van data vóór 1/1/1970 stelt zich helemaal niet, want dat kan momenteel ook niet opgeslagen worden in een UNIX date 32bit. Vandaag moet men óók een ander type gebruiken om deze data op te slaan.

Men moet gewoon systematisch beginnen met hiervoor een Int64 te gebruiken.
Dit doet me denken aan bepaalde bugs in een spel dat ik speel, de 25 dagen uptime bug. Bepaalde delen van het spel werken dan niet meer naar behoren omdat de aantal millisecondes sinds startup > int32_max gaat.
De windows functie in kwestie is timeGetTime.
Als iemand die vooral in Python werkt denk ik..."int32? int64? het is toch gewoon een int?" :+
Iemand die vooral in javascript werkt: int? float? het zijn toch gewoon numbers? ;)
Of voor iemand die op bit nivo werkt
Byte bit Real int dint signed word dword bin
He, een number? Ik dacht dat het een string was!
Gaat toch om het hoeveelheid bits dat de waarde inneemt? Java heeft ook int en long. Niet zo uniek aan python.
Python kent die scheiding niet. Daar is het gewoon een nummer, en zelfs als je boven de Int64 grens komt maakt dat iirc nog niet uit.
Klopt:

x = 9223372036854775807
>>> y = x**2
>>> y
85070591730234615847396907784232501249

Je kunt het nummer zo groot maken als dat je beschikbare geheugen toelaat (MemoryError).

[Reactie gewijzigd door Zarhrezz op 9 januari 2020 12:06]

Python 3 maakt er een goede abstractie van waardoor je geen maximum value hebt, maar dat werkt wel alleen maar zolang je binnen Python blijft. Als je wilt communiceren met andere systemen met een binary formaat dan ga je toch even moeten stilstaan bij hoeveel bits je gebruikt.

Python kent de scheiding wel, maar heeft die verplaatst naar het moment wanneer je je interne data omzet naar een formaat dat doorgestuurd kan worden. Kijk bijvoorbeeld even naar Python 3 struct. Daar staat er dus wel duidelijk in een tabel hoeveel bytes elk type inneemt. En als je daar geen boundary check doet kan je dus in de problemen komen.

Neemt niet weg dat het een slimme move is geweest van Python om het zo aan te pakken. Je moet er nu enkel aan denken wanneer het echt nodig is.
Ik had het bericht niet goed gelezen inderdaad. Ik las denk ik
"iemand die vooral in Python werkt denk ik." niet Als iemand 8)7
Omdat ik toevallig nog nooit wat in python gedaan heb

[Reactie gewijzigd door daellat op 9 januari 2020 15:19]

Is dit echt wel "goed geimplementeerd"? Met een 32-bit getal heb je een bereik van 136 jaar, maar een beetje meer dan met de "twee digits" oplossing. Bovendien was het bereik nog zo gekozen dat de helft daarvan voor 1970 valt.
Unix time is uitgevonden begin jaren 70, en was toen goed voor nog 68 jaar verder te gaan. Dat is toch echt wel wat verder dan al die applicaties die eind jaren '90 nog altijd Y2K vulnerable waren.

Er wordt trouwens al aan een oplossing gewerkt. De meeste operating systemen gebruiken ondertussen al een klok die verder gaat dan 32bit Unix time. In de praktijk hebben ze er vaak gewoon 64 bit van gemaakt om intern mee te werken. Er zijn natuurlijk nog een hoop APIs die nog niet zijn veranderd, en veel embedded systemen gebruiken nog 32bit Unix time, maar toch. We hebben nog 18 jaar te gaan en er wordt gewerkt aan oplossingen.

Er is dus meer dan tijd genoeg om het op te lossen. De keuze in het begin van de jaren '70 was dus echt niet zo kortzichtig. Ik denk gewoon dat het toen onmogelijk was om voor te stellen op hoeveel plaatsen computers zouden gebruikt worden, en hoeveel van die use-cases embedded computers zijn die moeilijk te upgraden zijn. We praten over 5 jaar voor de Apple 1, en 10 jaar voor de IBM PC. De integrated circuit begon op dat moment nog maar net door te breken na een succesvolle demonstratie bij de maanlandingen. 32 bit gebruiken was toen echt wel vooruitstrevend. Je moet het allemaal even in context plaatsen. Ik denk niet dat je beseft hoe veel er veranderd is sinds 1970.
Int32 is maximaal 2147483647
In GTA Online als je dat geldbedrag limiet hebt bereikt, krijg je te maken met bepaalde bugs zoals je kan je mechanic niet meer bellen, je dagelijkse rekeningen betalen zoals bezit van je garage(s) en je kan ook niet meer douchen :+
Dat niet kunnen douchen snap ik wel, je bent dan echt stinkend rijk.
Het Y2K probleem is ook veroorzaakt door een technische beperking, namelijk weinig geheugen en peperdure opslag.
Heeft weinig met luiheid te maken.
Na 19 januari 2038 zouden ook de volgende jaren nog problemen op kunnen leveren :

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

2046: Amiga's (op specificiek 19 Januari, 2046, 03:14:07. telt vanaf 1978 in 32-bit)

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)

en zo zijn er nog een heleboel anderen op specifieke niche markten/producten...

[Reactie gewijzigd door warrg op 9 januari 2020 10:45]

Ja dat herinner ik me nog wel - oeps even een confrontatie met hoe lang ik al in het vak zit O-) . Vaak werd er gekozen niet het datatype op te rekken van 2 naar 4 cijfers, maar logica toe te voegen. "Als jaar <20 dan 20xx, anders 19xx". Die parkeermeters denken nu dus dat het 1920 is 8)7

[Reactie gewijzigd door dixet op 9 januari 2020 09:48]

Helaas gebeurd dat nog steeds. Laatste een patch van een bepaald CMS mogen implementeren. En zie gewoon letterlijk in de code een wijziging die kijkt naar het 3de getal van het jaar. Als 9 dan 199x, als 0 dan 200x, als 1 dan 201x.

En nu de patch was de toevinging, als 2 dan 202x... :/
Ik voorzie een probleem over zo'n 10 jaar ;-),
Dat dus. Ik moest aardig hard zuchten toen ik 't zag.

Maar ja. Over 10 jaar gebruiken we vast een SaaS oplossing en zie ik deze meuk niet meer.
Dat dachten ze ook toen ze de vorige fix maakten denk ik ;-).

Maar ach het houdt je bezig :-P.
Ik denk niet dat ze ruim 20 jaar geleden aan SaaS hebben gedacht. ;)
Nee, maar wel dat er daartegen een betere oplossing zou zijn en deze hack al lang terug verdwenen was.
Saas is een recentere naam voor een opzet die al sinds de jaren 60 speelt. Thin clients e. d vormen de basis met decentrale installaties.
Is vooral een modeterm
SaaS is iets anders dan thin clients/mainframe computing, software die je gekocht en geïnstalleerd hebt op een server/mainframe veranderd/verbeterd zichzelf niet/tot nauwelijks in tegenstelling tot een SaaS platform welke vaak continue in beweging zijn.
Je kon 30 jaar geleden ook al thinclienten via internet; dus gewoon SaaS. Een website bezoeken kan je eigenlijk ook wel als SaaS zien.
Gewoon een hypenaampje , marketing voor oude koek in een nieuw jasje.
Totdat je SaaS oplossing gewoon je applicitatie is die gewoon naar de cloud is geramd met een maandelijkse abbo om alleen de hosting te dekken
hosting kosten + licentie kosten + support + updates + beheer +uptime garanties
SaaS is iets meer dan een applicatie op een Azure/AWS VM plaatsen.
Ja duh day weet ik ook maar je moet ze de kost eens geven die dat niet zo zien
Wie weet over 5 jaar al. 25 jaar als grens tot 2025 is ook niet gek, evenmin als 35. Iedereen heeft zijn eigen grens gekozen dus dit probleem zal nog wel decennialang blijven bestaan.
Pfff... nu was 1999 ook wel zo’n jaar waarin zo’n beetje elke amoebe die zichzelf IT’er noemde een dik salaris plus leaseauto kreeg. Keer op keer blijkt weer dat software schrijven toch echt een ambacht is...
Maar die amoebes deden over het algemeen geen programmeerwerk. Die kregen twee weken Windows NT bootcamp, moesten de examens doen en werden gedumpt bij de klant.

Goeie tijden waren dat, het leek wel het wilde westen. Denk er af en toe met enige weemoed aan terug. :)
Haha dat zag ik afgelopen week ook in een Sap implementatie 8)7 8)7
Helaas gebeurd dat nog steeds.
Ach, het houdt iemand van de straat :+
En een paar mensen OP de straat om die 14.000 parkeermeters af te lopen.
Die snap ik niet helemaal. Als je voor het jaar 2 cijfers gebruikt, hoe kun je dan op 1920 uitkomen?
Origineel werd als jaar alléén de laatste 2 cijfers gebruikt, en stond de 19 vast. 89 was 1989, 00 was 1900, etc.

Als oplossing voor die beperking werd simpelweg een extra stukje code toegevoegd zoals het artikel noemt in plaats van het jaartal 4 cijfers te maken:

als <20 dan prefix 20

als >=20 dan prefix 19

Maar dat levert dus de huidige problemen op :)
En dan vraag ik me af waarom er 20 gebruikt wordt als drempelwaarde en geen 50 of 70.

Want voor 1950 of 1970 had je geen grootschalige computernetwerken, en ik mag toch verwachten dat alle computers die in de periode vóór 2000 zijn gebouwd en actief in gebruik zijn, toch wel na 2050 in de container zijn beland.
Dat er toen nog geen computers waren impliceert nog niet dat je geen datums in wilt kunnen voeren van rond die tijd.

Een beetje gerelateerd voorbeeld was toen mijn vader een afspraak voor mijn opa wilde maken bij de gemeente, dat moest via de website van de gemeente. Mijn opa was toen 101. Het invoerveld voor het geboortejaar was een dropdown met individuele jaartallen die maar 100 jaar teruggingen. En daardoor kon het systeem de burger dus niet valideren |:(

[Reactie gewijzigd door .oisyn op 9 januari 2020 10:36]

Ik denk dat je daarin onderscheid moet maken tussen echte time-stamps, waarin het daadwerkelijke tijdstip in seconden ook van belang is, en pure dag/datum entries waar de interne klok van de computer zelf weinig mee te maken heeft.

Als je het jaartal in je eigen database niet in 4 cijfers opslaat (of verwacht dat een user maar een bepaalde range aan invoer geeft), dan doe je sowieso ergens iets gigantisch fout...
Als je het jaartal in je eigen database niet in 4 cijfers opslaat (of verwacht dat een user maar een bepaalde range aan invoer geeft), dan doe je sowieso ergens iets gigantisch fout...
En het wordt pas echt leuk als je beseft dat onze jaartelling niet de enige is die op deze aarde wordt gebruikt. Als je software overal wil kunnen inzetten mag je er niet van uitgaan dat het ongeveer 2020 is.
Er zijn weinig ICT zaken zo complex als datum/tijd rekening.... met name omdat dit een politiek gedreven issue is.
[ tijdzone's bv. gaan we in NL straks permanent in zomertijd leven..., klinkt leuk.., maar het is wel 1 3/4 uur tijdverschil met zonne tijd. Je leeft dan ongeveer op de Ukrainsche klok. (NL zonne tijd is ~ 15 minuten voor UTC/GMT) ]
Feitelijk is UTC in NL invoeren het beste voor de biologische klok.
The Problem with Time & Timezones - Computerphile: https://www.youtube.com/watch?v=-5wpm-gesOY

[Reactie gewijzigd door jbvo op 9 januari 2020 13:11]

yup... ik kan je beoordelings score niet instellen... maar voor mij +2

[Reactie gewijzigd door tweaknico op 9 januari 2020 13:13]

[Off Topic]
Feitelijk is UTC in NL invoeren het beste voor de biologische klok.
Dat argument hoor ik vaak, maar is naar mijn mening slechts beperkt van toepassing, omdat veel mensen gewoon hun leven inrichten volgens hun eigen biologische voorkeur. Zo staat mijn vrouw enkele uren voor ze naar kantoor gaat op, en ikzelf pas ongeveer 30 minuten voor vertrek. We leven zo allebei al in een andere 'tijdzone', hoe dat de buitenwereld die inricht gaat dat echt niet veranderen. Hooguit ga ik iets meer voor vertrek thuis doen, en iets minder na aankomst thuis, of vice versa, danwel mijn werktijden anders inrichten.
Onderzoek lijkt uit te wijzen dat als je ver van de natuurlijke klok opstaat etc. dat dat serieuze gevolgen heeft voor gezondheid... net als onregelmatig werker een aanslag is op de gezondheid.
Persoonlijke ritmen hebben weinig van doen met klokwijzers. maar wisselingen zijn erger dan constant scheef. Er zijn ook enkele mensen die liever 's nachts actief zijn...., maar om daar de hele handel op in te richten.
https://www.rivm.nl/nieuw...sgezondheid-dan-zomertijd

btw. UTC/GMT is niet CET (EU Tijd)...,
Voor NL: Meest westelijke puntje is ongeveer: 3,36 Oost, meest oostelijke puntje is ongeveer: 7,27 Oost. gemiddelde zonnetijd voor NL is ~ 5 graden oost. van UTC, 15 graden is 1 uur, dus ~ 20 minuten oostelijk van 0 meridiaan). Heel strict is Cadzand Bad 12 minuten voor GMT, en Bad Nieuweschans 30 minuten voor voor GMT.
CET (de huidige winter tijd is eigenlijk de klok van Berlijn/ Szczecin...(~15 oost), voor 2 uur tijdsverschil zetten we de klok gelijk met die van 30 graden oost ~ Kiev).
[Quote]
als je ver van de natuurlijke klok opstaat
[\Quote]
Dit was precies mijn punt, hoe en wanneer ik opsta en ga slapen is niet afhankelijk van hoe laat het is (zomertijd/wintertijd/utc), maar meer afhankelijk van de flexibele werktijden en mijn persoonlijke voorkeur.
Of dat 7:00, 8:00 of 6:00 genoemd wordt vind ik niet zo interessant.
Alleen worden veel mensen NIET FLEXIBEL om 08:45 op hun werk verwacht. Dus geen natuurlijke opstaan tijd, maar gewoon de klok volgen. (mensen verwachten wel dat een winkel om 09:00 op gaat.
Zelfs als je werktijden niet flexibel zijn, kan je nog steeds kiezen om:
- dichter bij je werk te gaan wonen.
- dingen 's avonds doen in plaats van 's ochtends
- of, als je liever eerder op wilt staan, dingen 's ochtends doen in plaats van 's avonds.
Volgens mij is er voldoende mogelijk om te schuiven, en daar waar dat niet mogelijk is heeft dat doorgaans te maken met de aard van het werk, en dat verandert niet wanneer je er voor kiest om de klok te verzetten.
Daardoor heeft het m.i. veel minder impact dan door de veel gehoorde argumentatie wordt gesuggereerd.

Het totaalbeeld is veel genuanceerder, en het enige dat wetenschappelijke studies aantonen, is dat je beter in harmonie met je bioritme kunt opstaan, je zult mij dat ook niet horen ontkennen.
Het lijkt er echter op dat er automatisch vanuit wordt gegaan dat het daarom beter is om de klok te verzetten. Dat vindt ik veel te kort door de bocht, m.i. zijn er betere dingen te verzinnen die meer hout snijden, zoals b.v. werknemers meer keuze te geven voor flexibele werktijden.
Immers de een heeft 10 minuten reistijd, en de ander een uur en 10 minuten, en ik kan me zo voorstellen dat die 8:45 voor de een prima is, maar voor de ander niet. Verzet je de klok een uur, dan is het wellicht andersom. Dat probleem los je dus niet op met het kiezen van een andere tijdzone.
Goed dan zijn we het eens.. We zetten de klok, Kiev-tijd ipv. Amsterdam. en we gaan voortaan tussen 10 en 11 aan het werk... (winkel tijden naar 11 uur open etc.).
Als je geen serieuze argumenten weet te vinden, trek ik me uit deze discussie terug.
Het is wel degelijk serieus.....

Het natuurlijk zonlicht is (zonsopgang -zonsondergang) is voor ons (NL) gemiddeld op GMT+0:20 ( 20 minuten voor GMT/UTC).

De CET wintertijd staat op Berlijn tijd (GMT/UTC +1:00) en de Zomertijd staat op Kiev tijd ( GMT/UTC + 2:00).
Dus als je mensen biologisch het minst will belasten en je wil de klok tijden aanhouden voor winkel/bedrijfs openings tijden etc. Dan is GMT/UTC+0:20 ideaal, Op hele uren afgerond GMT/UTC de beste benadering of Als we in EU een geheel willen houden mogelijk GMT/URC +1:00 de huidige wintertijd het minst slechte alternatief, maar dat laatste is voornamelijk uit economische overwegingen.

Als de biologische klok van belang is (levensduur van mensen wordt hierdoor beinvloed), en winkel openingstijden zijn gereguleerd zoals in NL dan moeten de winkel/bedrijfs openings tijden in sync gebracht worden met de biologische klok. Dus als we Kiev tijd willen invoeren, en rekening willen houden met de beste omstandigheden voor de inwoners van NL dan is 11:00 als standaard bedrijfs openings tijd een gelijkwaardig alternatief.
dan doe je sowieso ergens iets gigantisch fout...
En dat gebeurt dus aan de lopende band. Point in case: ChromeBallz in 'geek: Twintig jaar oude millenniumbug sloeg op 1 januari opni...

Maar veelal gaat het om legacy systemen, en geheugenruimte was vroeger kostbaar. Dus bespaarde je wat uit door een jaartal-veld maar uit 2 cijfers te laten bestaan.

[Reactie gewijzigd door .oisyn op 9 januari 2020 10:46]

Maar veelal gaat het om legacy systemen, en geheugenruimte was vroeger kostbaar. Dus bespaarde je wat uit door een jaartal-veld maar uit 2 cijfers te laten bestaan.
Ik had begrepen dat ook dat een myth was, het was meer een gemakzucht of gebruik. Ik kan me ook niet voorstellen dat 2 cijfers meer een groot verschil zou maken, zelfs in die tijd. Misschien heeft iemand een bron?
Meer persoonlijke anekdote dan een echte bron. Maar denk niet zo zeer aan computers maar aan microcontrollers qua y2k.

Eind jaren 90 ontwierp ik anti-inbraak en anti-winkeldiefstal systemen. Vooral de pic 16f84 gebruikte we veel en dan had je maar iets van 64 bytes aan geheugen. Dan is die extra twee bytes voor het jaar in eens een stuk kostbaarder. Om het op te lossen moesten we het aantal unieke gebruikerscodes dat mogelijk was inperken om een extra byte vrij te krijgen. Als die 9 was, dan was het 1900-1999, elk ander getal en het was 2?00-2?99. Dus als iemand nog een oud alarm installatie heeft van ons zit je tot 2899 goed. ;)

Bij ieder systeem met onderhoudscontract, nog onder garantie of op verzoek voor kostprijs werd die microcontroller vervangen met een y2k bestendige software versie. Niet dat er een echt probleem was als hij niet werd vervangen, het alarm bleef gewoon werken. Sommige wouden de fix bewust niet vanwege die beperkte hoeveelheid unieke gebruikerscodes.

Y2K was imho een storm in een glas water. Kan iemand zich trouwens nog herinneren wat iig RTL4 toen deed om middernacht? ;)
Op RTL4 zal er vast iets met Gordon en Gerard Joling zijn geweest, maar eerlijk gezegd geen idee. Ik was aan het werk die avond met mijn bijbaan in een disco en wat ik mij daarvan herinner was, naast het veelvoud van het reguliere salaris en behoorlijke fooien, dat we alle klanten in de maand daarvoor al waarschuwden om tijdig te zorgen voor voldoende contanten en dat we die avond uitsluitend contant accepteerden i.v.m. risico op uitval betaalautomaat en ook het dichttimmeren van pinautomaten in verband met het vuurwerk (toch ook een oude discussie). De waarschuwing voor Y2K hadden dus in ieder geval hun werk wel gedaan.
Y2K was imho een storm in een glas water.
Ik weet dat bij de ABN-AMRO ze voor 99,995% zeker wisten dat alles goed zou gaan, maar toch kreeg een shit-load van het "midden management" niveau de hele dag stand-by dienst tegen 200% loon, en dat was meer een verkapte bonus. ;)
Je moet meer naar het begin van het computer tijdperk, meer richting de jaren '50 en '60. In die periode was iedere bit kostbaar en was het kunst om met zo weinig mogelijk resources je werk te doen.
In de jaren '90 was dat niet meer het geval maar dat wil niet zeggen dat de software opnieuw geschreven was of dat de programmeurs in die tijd het al afgeleerd waren om het te doen.

Overigens gebruiken we nog altijd integers, strings, boolean, float, single, etc om werkgeheugen aan te spreken. Waarom gebruiken we geen generieke variabele (var)? Resources, en dat is 2020.

[Reactie gewijzigd door sprankel op 9 januari 2020 11:24]

Overigens gebruiken we nog altijd integers, strings, boolean, float, single, etc om werkgeheugen aan te spreken. Waarom gebruiken we geen generieke variabele (var)? Resources, en dat is 2020.
Nee hoor dat is op een hoger niveau. Machinecode kent alleen bitjes die op een bepaalde plek in het geheugen staat.

Waarom je in hogere programeertalen types gebruikt, https://en.wikipedia.org/wiki/Type_safety.
Er zijn meerdere redenen uiteraard, je declareert een integer en je hoeft je niets aan te trekken van de memory stack, het effectieve memory adress (je variabele geld als pointer) en je hoeft je ook niets aan te trekken met het opkuisen van je geheugen. In lagere talen gaat dat wel eens fout met een memory leak tot gevolg.
Daarnaast laat het de compiler toe om code anders te interpreteren, je kan andere dingen doen met een string (tekst) dan met een integer (getal). Als je het met een generieke variabele gaat werken (var) dan gaat dit iets lastiger.

Echter waarom gebruik je een boolean op 0/1 of false/true in plaats van een integer die je op 0 of 1 zet? Of nog beter, waarom gebruik je een integer (geen komma) in plaats van altijd een float te gebruiken (wel een komma)?

Omdat een boolean minder resources vraagt dan een integer en omdat een integer minder resources vraagt dan een float. Je declareert enkel een float als je daar nood aan hebt.
Mijn VIC-20 computer had maar 3,5 kb RAM geheugen. Een paar bytes meer of minder maakt dan echt wel uit.
In 1980-1985 koste 1MB geheugen ongeveer 1M $.. een $ / byte.
Disks 60MB (formaat was machine) voor de prijs van een leuke auto... (20+ K NLG).

Veel systemen hadden op z'n best 32 - 64K om mee te werken.

Dus een paar bytes voor eeuwcijfers uitsparen leverde een hoop op.
Alleen is management nog steeds niet doordrongen dat de besparingen van toen nu een veelvoud kosten om te fixen.... in de hoop dat het probleem door een ander opgelost gaat worden.
Ik betwijfel of je toestemming van een project leider krijgt om de codebase op vergelijkbare issues to doorzoeken... want "wie gaat dat betalen"...

Dit effect heeft ook wel eens "technical debt"...
[..] ik mag toch verwachten dat alle computers die in de periode vóór 2000 zijn gebouwd en actief in gebruik zijn, toch wel na 2050 in de container zijn beland.
En juist die aanname zorgt, 20 jaar na dato, nog steeds voor problemen 8)7
Klopt, eerste automatisering was het omzetten van papierstroom in digitaal. Aanname was toen dat je altijd weer handmatig aan de gang kon gaan in nood.
Inmiddels zijn er zoveel stromen en bewerkingen, dat de processen niet meer handmatig uitgevoerd kunnen worden.
Maar een computer van na 1950 kan best gegevens verwerken over dingen van voor 1950.
Bijvoorbeeld een geboortedatum.

Als ze toen voor een quick fix zijn gegaan met de gedachte dat er daarna tijd zou zijn voor een definitieve oplossing dan is 20 jaar niet zo gek.
-1920 is ver genoeg in het verleden om niet (in alle gevallen) relevant meer te zijn.
-2020 is ver genoeg in de toekomst om je klanten te zeggen dat het echt is opgelost terwijl je rustig aan een definitieve oplossing werkt om die dan stilletjes uit te rollen.

En als de jaarwisseling van 2000 dan goed gaat dan is de druk om door te pakken met die definitieve oplossing ook weg.
En dan vraag ik me af waarom er 20 gebruikt wordt als drempelwaarde en geen 50 of 70.
Bijvoorbeeld omdat veel oude administratieve systemen van bedrijven geboortedatums gebruiken. Veelal wil je met het bepalen van de eeuw dus tot zo'n 65 of zelfs meer jaar in het verleden kunnen gaan en maar heel kort richting de toekomst.
Een goed alternatief wat ik zelf geimplementeerd heb in een systeem is:
als jaar <= sysjaar + 20 => eeuw is 20
als jaar > sysjaar + 20 => eeuw is 19
En dan vraag ik me af waarom er 20 gebruikt wordt als drempelwaarde en geen 50 of 70.
De bedrijven die 20 hebben gekozen zullen er hun redenen voor hebben gehad. Maar niets iedereen koos 20 als grens. Van bedrijven die 50 als grens hebben genomen hoor je dit jaar niets. Pas in 2050 spelen daar dezelfde problemen. Dan zal er vast iemand zijn die vraagt 'waarom niet 70'.
Tsja .. ik heb alle jaar 2000 scans gedaan bij mijn toenmalige werkgever. Vergeet niet dat bij Mainframes programma's ZEER lang leven: er draaien daar nu nog programma's uit de 80-tiger jaren. Dus de computers zijn wel vernieuwd, de programma's niet. Waarom ook: goed = goed. En de drempelwaarde van b.v 20 is (was, toen) voor de hand liggend: er worden ook geboortedata opgeslagen, en ook toen werden mensen oud. En ja .. er is toen vaak voor een oplossing die 10 - 20 jaar werkt gekozen. Niet zo gek: toon mij eens een programma op een server in welke servertaal ook dat meer dan 20 jaar probleemloos draait ? We dachten toen idd dat dit in de komende 20 jaar wel opgelost zou worden. Maar ja ..
Maar waarom zou je de grens zo laag kiezen?
Waarom niet <80 bijvoorbeeld?
Het gaat ook over pensioen systemen en je wil in 2000 niet alle 20+ mensen hun pensioen ontzeggen omdat ze volgens de administratie nog geboren moeten worden.

En 20 jaar zou voldoende zijn om de problemen WERKELIJK aan te pakken.
op 2 januari 2001 waren alle spannende zaken klaar en kon management het definitieve reparatie werk i.v.m. de kosten in ieder geval uitstellen naar de volgende manager. die kon het ook nog een keer doorschuiven en daarna wist niemand (op management niveau) meer dat er nog wat moest gebeuren... geschiedenis herhaalt zich weer.

[Reactie gewijzigd door tweaknico op 9 januari 2020 13:33]

Is t nu dan wel goed gefixt?
Of krijgen we straks de Y2K2X2-bug over twee jaar? (om maar bij t cijfer 2 te blijven)
Natuurlijk niet... (in het algemeen).... mogelijk in sommige projecten.

Het zou Y2K22 of Y2022 zijn voor de juiste notatie. En nee niet over 2 jaar eerder over 10 of 20 jaar omdat de grens verschoven wordt, zodat het huidige management het weer met een gerust hart kunnen doorschuiven naar de toekomst.
Dat dacht ik ook, maar het kan natuurlijk wel zijn dat er ook veel data was met oudere jaartallen, dichter bij die 20. Je wilt dan niet dat die data ook 20 als prefix krijgt.
Maar waar baseer je de conditiestelling op als je de eeuw niet gebruikt en dus niet weet?

If (conditie) then jaar=20xx else jaar=19xx
Bij jouw voorbeeld ontbreekt die gewoon.
het rare was dat de eeuw WEL gebruikt werd....
Maar uit ruimte overwegingen niet opgeslagen werd. (1985: 1MB ram kosten in USD 1M
60 MB disk kon je ook een leuke auto voor kopen).
Dus jaartallen samen voegen tot 2 cijfers levert een hoop ruimte winst op.

(ok omdat in het spraak gebruik de eeuw niet echt gebruikt wordt... '20, '99 etc.)
Dus eerst was de aanname dat eeuw ontbrekend = 1900 OK. vanaf het jaar 2000 niet meer.
later is het jaartal voor de keuze van eeuw cijfer aangepast naar '20 of '30... (afhankelijk voor hoever men terug moest.). '20 was een populaire keuze immers na de quickfix die ineen jaar op orde moest zijn was er voldoende tijd om het echt op te lossen.
Op 1 januari 2002 slaakte de wereld eenzucht van verlichhting er was immersniets gebeurd... het zou een Hoax zijn etc. etc. waardoor ook de nog vereiste ECHTE fix, het gebruik van 4 cijferige jaartallen niet meer uitgevoerd is).
Been there done, that...
Wat eigenlijk idioot is, want ook voor een getal van 0-100 heb je 1 byte nodig. (Strikt genomen, een halve byte, maar er zijn weinig computers die met 7 bits data werken).

Dus waarom ze dan een integer van 0-100 opgeslagen hebben en niet gewoon een offset vanaf 1900 is me een raadsel, want dan zou je op zijn minst tot 2155 vooruit kunnen.
Dit gaat vrijwel altijd over administrattieve systemen en dan zijn het strings van 2 tekens.
Met BCD was het ook makkelijk 4 cijfers geweest.

Maar met binaire data gaat het mogelijk ook fout...
op Dinsdag 19 januari 2038, om 04:14:07 gaat de Unix tijd sinds start (1-jan-1970 = 0)
van hex 0x7fffffff -> 0x80000000 en dat betekent dat de tijd ineens negatief wordt (de unix tijd is nl een signed integer), inmiddels zijn er 64bit systemen waar dit voor de kernel minder een probleem is, maar hoeveel systemen zijn er gebouwd op 32bit... of op basis van de 32 bits definitie voor opslag.
Dit is bekend als het Y2K38 of Y2038 probleem.

Een ander systeem OpenVMS gebruikt 64 bits signed getallen voor timestamp, en meet de tijd in 100 nanoseconden eenheden sinds November 1857 ( de dag dat de sterrenkundigen over gingen van julian (JD 2400000.5) tijd naar smithsonian tijd - Julian tijd was van 12 uur 's middags - volgende dag 12 uur 'smiddags) en VMS tijd kan voort tot voorbij het jaar 31000.
Voor meer info: https://www.slac.stanford.edu/~rkj/crazytime.txt

[Reactie gewijzigd door tweaknico op 9 januari 2020 12:57]

Dit gaat vrijwel altijd over administrattieve systemen en dan zijn het strings van 2 tekens.
De meeste oude admnistratieve systemen die ik ken gebruiken packed decimals voor datumvelden.
Hangt er maar vanaf... Als het in COBOL geprogrammeerd was vast.. Al bestonden er ook al databases waarbij vaak stringvelden gebruikt werden.. (SQL date was al een stuk veiliger geweest., maar vereist berekeningen tijden presentatie en dat kost performance... ).
Oude administratieve systemen waren voor 90%+ procent in cobol gebouwd.
Cobol is gewoon heel goed als systeemsoftware voor gegevens administratie.
Dat ontbreekt niet, dat is precies die hele conditiestelling.
If (conditie) then jaar=20xx else jaar=19xx
Is dus
If (year<20) then jaar=20xx else jaar=19xx
Ze gingen er waarschijnlijk van uit dat 20 sowieso pas in 2020 voorkomt, dus dan kun je er 20 voor plakken. Ik weet niet wanneer de aanpassingen allemaal werden gedaan, maar als bijvoorbeeld 99 nog moest komen, zou daar dus 19 voor geplakt moeten worden, dus als >= 20, dan prefix 19.
Op die manier breek je niks in de software, maar voeg je alleen een klein stukje code toe wat de prefix aanpast die ervoor fixed was op 19.

Waarom die 20 weet ik niet, ze hadden ook bijvoorbeeld 80 kunnen pakken, want die zou ook pas weer voorkomen in 2080.

[Reactie gewijzigd door mjz2cool op 9 januari 2020 12:16]

Als het bedrijf al bestond in 1980 en ze al gebruik maakte van PC's dan zou het voor kunnen komen dat alles wat je in 1980 gedaan hebt ineens in 2080 zou zijn, of je moet daar ook weer extra code voor schrijven.

Ze hadden denk wel 1960 of misschien 1970 kunnen kiezen, zal uiteraard afhangen wanneer een bedrijf is begonnen met digitaal opslaan.
Daar had ik nog niet aan gedacht inderdaad, er is in veel gevallen ook een bepaalde historie die nog moet kloppen.
Hangt er vanaf waar je het jaartal voor gebruikt. Als dit een geboortdatum is/was dan moet je ook rekening houden met personen die bijvoorbeeld in 1910 zijn geboren. Als het om geboortedata van beroemde mensen uit de geschiedenis gaat dan moet je nog veel verder terug kunnen. Jaartallen worden niet alleen gebruikt als timestamp voor het opslaan van data (date created/date modified) maar dus ook voor andere zaken.
Het ging met name over administratieve systemen (bv. pensioen berekening etc.) en dan is het 80 jaar terug kunnen in de tijd best een belangrijk gegeven.
Conversie van bestanden is ook een dingetje... (om de jaartallen op te rekken).
Maar waar baseer je de conditiestelling op als je de eeuw niet gebruikt en dus niet weet?
Op de waarde van wat je wel weet.

Stel yy is een variabele die uit je database komt en bereik 0..99 heeft.

Vóór het aanpakken van de milleniumbug was de code:

jaar = 1900 + yy

Dat levert nooit een resultaat groter dan 1999 op.

In dit geval is de code kennelijk aangepast tot:

if (yy<20) then jaar=2000+yy else jaar=1900+yy

Dat kan alleen waarden opleveren die lopen van 1920 tot en met 2019.
En in 2020 loop je dus weer tegen een probleem op.

[Reactie gewijzigd door Brousant op 9 januari 2020 10:37]

De conditie bestaat uit de jaartelling in 2 cijfers. Dus iets als 20.
Ja kom zeg, denk een beetje na, of lees je in in het y2k probleem. De waarde wordt uitgelezen uit een een of andere bron. Daar staat die opgeslagen met maar 2 cijfers.
Het y2k probleem ging over een teller met 2 digits die weer op 0 komt na 99. Dat is iets anders. Ik ben wel benieuwd naar de logica die 2020 in 1920 verandert...

[Reactie gewijzigd door blorf op 9 januari 2020 10:45]

Dat staat hierboven ergens uitgelegd.
Ik denk dat het ermee te maken had dat men niet verwachtte met mensen ouder dan 80 jaar te maken te krijgen. Dus als 't geboortejaar voor '20' lag zal 't wel 2020 moeten zijn geweest.

[Reactie gewijzigd door ajolla op 9 januari 2020 12:22]

Klopt ik heb zelf jaren gewerkt aan pensioensystemen in COBOL en ORACLE. In de pensioenwereld betaal je premie voor je pensioenopbouw, meestal vanaf je 25e tot je pensioendatum die op 65/55 lag. De mensen in het opbouwsysteem zijn dus altijd jonger dan 65, want dan gingen ze met pensioen en werden ze overgeheveld naar het uitkeringensysteem. Hier waren de mensen dus altijd OUDER dan 55 en werd ook een andere (jaar)grens gebruikt voor de jaartal. Bij de ORACLE systemen met SQL werd de volledige geboortedatum wel opgeslagen. Schijfruimte was aanmerkelijk goedkoper geworden
Niet per se, het y2k probleem is veel breder dan alleen tellertjes, maar de kern van alle y2k problemen is dat je het moet doen met slechts 2 cijfers. Of dat nou een teller is of op die manier is opgeslagen of ingevoerd.
Ik ben wel benieuwd naar de logica die 2020 in 1920 verandert...
if(<20) then eeuw=20
if(>=20) then eeuw=19

Ze zijn er gewoon van uit gegaan dat met bijvoorbeeld 15 het jaar 2015 wordt bedoeld en niet 1915.

Lees ook mn andere reactie:
geek: Twintig jaar oude millenniumbug sloeg op 1 januari opnieuw toe

[Reactie gewijzigd door mjz2cool op 9 januari 2020 12:18]

20 = 1920 en 19 = 2019 er wordt een compare gedaan op de twee cijfers waarschijnlijk omdat het datatype veranderen teveel moeite was.
Gaat niet om het datatype. Ram, storage en bandbreedte waren ontzettend duur vroeger, dus elke bit die bespaard kon worden was de moeite waard.
Hij onthoudt alleen maar '15, of '95 of iets in die geest, en plakt er dan standaard 19 voor. Aangezien '15 meest recent als 2015 voorkwam is dat niet heel wenselijk, dus voegen ze er nog wat logica bij, namelijk het regeltje van dixet.

Dus dan onthoudt ie '15, bedenkt dat het onder de 20 is, dus plakt hij er 20 voor, resultaat : 2015.
Nu weet de computer dat het '20 is, dat is niet kleiner dan 20, dus plakt hij er 19 voor. En opeens leef je in 1920! Tijdreizen was nog nooit zo makkelijk :P
Parkeren wel maar 3 cent ipv 5 dollar, scheelt toch.
Een paar weken geleden (dus voor deze bug) parkeerde ik op straat in een populaire wijk van NYC voor $0.75 per uur. Het is daar geen Amsterdam :)

(maar een paar dagen later in een klein stadje voor $4,75 en werd ik alsnog weggesleept :( )
Precies.
Maar dit is een management dingetje.
"Wat kost het"?
1. Een goede oplossing, dus alle datums met yyyy, kost veel.
2. Een kleine if then kost weinig.
Management: "optie 2"
Programmeur: "Zucht..."
Daarom vertel je als beetje programmeur nooit optie twee.
is wel 1 voordeel als je net 1 minut voor die bug er een muntje in zou gooien, dan denken die meters vast dat je nog een 100+ jaar mag parkeren
Of ze concluderen direct dat je tijd is verstreken, immers oorspronkelijke_tijd + parkeer_duur < huidige_tijd.

[Reactie gewijzigd door .oisyn op 9 januari 2020 17:05]

En de eerste voorloper van de creditcard werd in 1928 geintroduceerd, dus ja. Dan gaat het mis ;)
Ik moet bekennen dat ik vorige week precies zo'n bug gefixed heb in code die zo'n 20 jaar oud is.
In 1999 hebben ze al 'oude' COBOL-krassers van stal gehaald om die aanpassing te doen. Die verwachtten 2020 niet meer mee te maken (als actieve IT-er). :)
Wel suf dat ze daar niet van hebben gemaakt als jaar <95 dan 20xx.

Nog suffer is natuurlijk dat ze er niet gewoon een groter datatype hebben gebruikt, maar dat is soms veel werk en miss niet altijd mogelijk op de hardware.
Tenzij het gaat over mensen die in 1980 geboren zijn. Die komen dan plotseling uit 2080.
Ja dat is wel een probleem, echter is de huidige tijd van het systeem wel gewoon goed.

[Reactie gewijzigd door SpiceWorm op 9 januari 2020 13:41]

met een prijs van 1$ / byte was geheugen in 1980-1985 gewoon wat duurder, voor die tijd nog veel duurder.
machine moesten werken met 4, 16 of erg luxe machines: 32K geheugen.
(HTS Den Haag, 1980: PDP 11, 64K geheugen, moesten we wel met 14 man gelijktijdig op werken).

Met een dergelijke geheugen omvang is het handig om te besparen op alles waar je maar op kan besparen,
Bij mensen die in die tijd zijn opgeleid is dat met de paplepel ingegoten dan wel erin gehamerd...

Dus heb je daar dan nog een jaar of 10-15 naijl effecten van. naast de gewoonte van 90% van de mensen om jaartallen met slechts 2 cijfers aan te duiden. (feitelijk refererend aan de gregoriaanse kalender uit een bepaalde eeuw, maar dat staat er niet bij..)
Ik snap dat in de legacy code de besparing is toegepast idd, en uit gewoonte ook in 1990 nog werd toegepast. Wat ik wat suffer vind is dat er in de aanpassingen voor y2k niet gekozen is voor een datatype van 4 bytes of gewoon een short/uint. Lijkt mij wel een uitzondering dat dat niet kan. Maar miss is dat meestal wel gebeurd en zijn dit die uitzonderingen.
Dat ben ik met je eens. Maar een van de problemen was/is dat je voor het opnieuw runnen van oudere rapportages (soms nodig voor juridische claims) dan ook historische bestanden moet converteren.
Het was best een hoopwerk. In 1996 +/- 1 jaar waren de pensioen fondsen de eersten die het aan zagen komen, de rest begon in eind 1998 met iets van planningen en pas in 1999 met inventariseren en aanpassingen "want het zou zo'nb vaart niet lopen".... Toen was er heel veel haast en na 2 januari weer terug naar business as usual inclusief het vooruitschuiven van alle "geld verkwistende" zaken naar de toekomst.
En daar zijn we nu.. met de efenis van de managers uit 2002-2004.
Let wel voor een deel zijn er zaken ook goed aangepast, voor een deel waren het alleen problemen tijdens de jaar overgang bij actieve systemen (die konden op oudejaars dag uit en op nieuwejaars dag weer aan), en voor een deel met de jaar overgang met uitgeschakelde systemen (de hardware klok kon niet van 0-> 1, om dat 0 "onbekende tijd" betekende en dus niet naar 1 opschoof, idd feitelijk een Y2K1 probleem), die systemen moesten dus aan blijven of bij een onverhoopte herstart handmatig geholpen worden.
Precies, dus de computer van de Belastingdienst concludeert dat deze persoon -40 jaar oud is en dus geen toeslagen krijgt.
Een heleboel dingen? Maar ik ben benieuwd naar wat jij het allersufts vind in deze context ;).
Ben benieuwd of er in 2099 nog weerbarstige software draait uit de jaren '90 van de vorige eeuw... :) history repeats.
We zullen het vermoedelijk niet meemaken :+ maar de meeste software gaat volgens mij maar één of twee generaties mee kunnen
Dat is per definitie natuurlijk een denkfout. De software als basis zal dat voor gelden, maar in veel software zit code die gewoon hergebruikt wordt. Dus code uit product X, wordt hergebruikt in product Y, omdat het doet wat nodig is. Maar die oude code wordt niet in detail gecontroleerd, dus gaat de "fout" mee in nieuwe (variant/versie) software en daar denkt dan niemand meer bij na zolang het goed gaat.
Klopt en dat gaat soms ook spectaculairder mis.. 1e vlucht van Ariane 5... de boordcomputer was gebaseerd op de zeer succesvolle Ariane 4, foutje met een floating point conversie van een van de koerscontrole systemen ==> self destruct.). een heel dure vuurpijl. http://www-users.math.umn.edu/~arnold//disasters/ariane.html

Vlucht werd afgebroken na 37 seconden, terwijl het instrument slecht 40 seconden gebruikt werd en alleen de eerste paar seconden noodzakelijk was.
De float conversie was nodig omdat de Ariane 4 systemen 16 bits getallen verwerkten. en een deel van de Ariane 5 systemen 64 bits getallen aanleverden.
mmm hoeveel code draait nog van pakweg 40 jaar terug ? Niet iedere programmeur werkt aan libraries of paketten die hergebruikt worden. Er zijn altijd cases die je niet meeneemt dat één fout noemen is nogal hard.

Moeten programmeurs zich ook indekken tegen de 32bit datum? de 3kY bug? ... er is een grens aan hoeveel edge cases je kunt voor berekenen. 95-99% van alle software heeft een levensduur van enkele jaren.... het is dus niet zo gek er vanuit te gaan dat jouw pakket ook niet jouw zal overstijgen in levensduur.
Dat is nu juist de denkfout van de programmeurs.
Ik denk dat "voor de meeste software" dat wel klopt, we zien natuurlijk nu alle uitzonderingen waarbij het niet is gebeurd.
Hm mogelijk niet eens van de programmeurs, maar in iedergeval van project managers die laag gestelde budgetten moeten halen.
IMHO meer een management issue... ook dat het nu weer de kop opsteekt. Het had 20 jaar geleden echt gefixed moeten worden ipv. opgelapt...
Misschien wel, als hobby-projectje, zoals we nu ook nog oude autos uit 1920 hebben rondhobbelen... maar als het goed is zou tegen die tijd het meeste echt ge-update moeten zijn (helaas... draaien er her en der nog stukken code uit 1970, vaak ver verstopt, gevirtualiseerd, maar het draait)
De millenium bug...

Ik weet nog goed dat ik als jonge groene engineer continue op standby stond om massa's gecrashte systemen aan boord van koopvaardijschepen weer op de been te helpen. Het aantal computergestuurde systemen aan boord viel toen nog mee, mijn takenpakket viel onder navigatie en communicatie, de userbase was meer het probleem.

Onder de streep waren er veel krekels te horen die dagen.

Zeker weten dat een hoop mensen de zakken goed hebben gevuld met deze "ramp".
En die laatste opmerking vind ik dan weer spijtig. Ja, er is heel veel tijd en geld gestoken in het Y2K probleem, maar er zijn ook heel veel problemen verholpen voor ze zich konden voordoen en vele bedrijven hebben dan ook zwaar geïnvesteerd om zoveel mogelijk problemen te voorkomen. Vele bijkomende ondersteuning werd door vendors gratis aangeleverd.
Grappig dit. Als ik een schip had gekocht van misschien wel tien miljoen en het zou onbestuurbaar worden doordat de kalender een millennium passeert en ergens tegenaan varen, zou ik de leverancier mooi aansprakelijk stellen. En terecht. Laten we nou niet doen of die leveranciers dit uit de goedheid van hun hart doen. ;(
Nou nou,

Y2K of millenium bug wordt vaak aangehaald als "1 bug", maar is ondertussen een bijna generieke term omtrent alle datum/tijd bugs veroorzaakt door datatype-limitaties of programmeer shortcuts. En zo zijn er wel wat.

Jouw tien miljoen ship voorbeeld is relevanter dan je denkt :
De Deep Impact (ruimtesonde, niet de film) uit 2005 heeft na zijn originele missie nog andere onderzoeken kunnen doen, totdat ze in 2013 geen contact meer konden leggen omwille van een oneindige loop van reboots.
...the reason for the software malfunction was a Y2K-like problem. August 11, 2013, 00:38:49, was 232 tenth-seconds from January 1, 2000, leading to speculation that a system on the craft tracked time in one-tenth second increments since January 1, 2000, and stored it in an unsigned 32-bit integer, which then overflowed at this time, similar to the Year 2038 problem.
Andere specifieke praktische problemen :
> GPS rollovers : Datums werden in in weeknummer+weekdag opgeslagen. Om de 19,6 jaar (1024 weken) herbegint hij. Dat was zo in in augustus 1999 en in april 2019 en dus opnieuw in november 2038. Recentere systemen zijn in 13bit veld ipv 10bit en kunnen dus 8192 weken aan (157 jaar).
Dat kastje in je auto kan plots niet meer positioneren.

> in polen zijn duizenden kassas vorige week (3 januari 2020) verkeerde datums beginnen printen. (leg dat maar uit aan je boekhouder / belastingscontroleurs)

> in 2010 zijn miljoenen duitse bankkaarten geblokkeerd geweest omwille van datumverificaties

> Texas Instruments rekenmachines (zoals bv het model dat ik zelf nog in de kast heb liggen van m'n schooljaren) kunnen slechts jaren aan van 1950 tot 2049. Dat is misschien nog ver, tenzij je een lening wil berekenen op, ik zeg maar wat, 30 jaar. Dat zou vanaf ... +- nu... niet meer moeten lukken. (straks thuis eens proberen trouwens :P )

> in het bedrijf waar ik zelf werk (energieleverancier) wordt volop 2099 gebruikt als "fictieve" einddatum om aan te geven dat iets nog geen echte einddatum heeft. (Nu ja, ik hoop dat tegen dan (of nog veel vroeger) het hele systeem reeds op de schop is gegaan, }:O )

> Andere leuke voorbeelden die ik me herinner zijn bij het fixen van die Y2K issues (dus ter voorbereiding op), bleek bv in Schiphol dat na een test op de noodbaanverlichting opeens de normale verlichting niet meer werkte. Of dat omwille van een plc in de sluizen van IJmuiden de sluisdeuren niet meer automatisch open gingen. Dit zijn dingen die niet perse de pers haalden, want waar de overheid moet zijn (terecht), lopen bedrijven niet graag te koop met hun problemen. Iets met reputatie enzo...

Anyway,
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!!!!
Dat zeg ik toch juist?

Een supermarktketen die kassa heeft, heeft geen verstand van hoe die in elkaar steken. Die moet er op kunnen vertrouwen dat die dingen goed werken. Maar een kassafabrikant kan niet met droge ogen doen alsof ze dat niet hadden moeten testen.

Overigens is het nou ook weer niet zo dramatisch allemaal. Er zijn wel vaker storingen en fouten die ontdekt worden. Ik kreeg vandaag nog een terugroep-verzoek betreffende de airbag van een auto die al jaren afgeschreven is. Alsof datum-bugs iets unieks zijn. Was het maar waar.
En die laatste opmerking vind ik dan weer spijtig.
Lol. @Skyrunner heeft gelijk. Ik was toen al een paar jaar actief in de IT en ik heb heel veel uren geschreven door met een diskette met een klein dom programma'tje computers te checken door de datum overgang te simuleren. Ik ben in die tijd niet 1 systeem tegengekomen die niet door de test kwam. Maar wel uurtje factuurtje. Heel veel uurtjes gevolgd door factuurtjes. Plus dat ik in die tijd zeer veel nieuwe computer geïnstalleerd heb omdat er veel (onnodig) vervangen werd vanwege de angst voor een totale crash.
Het probleem was namelijk helemaal niet zo groot als verwacht. Veel systemen in die tijd waren de jaren daarvoor al voorzien van patches / updates enz.
Het was meer het idee dat iets fout kon gaan. Mijn broer zat in die tijd in het leger. Zelf daar stonden ze volledig standby omdat men bang was voor the end of time. Het liep af met een sisser.
Ik ben er van overtuigd dat de leiding (van het leger, maar ook van Schiphol etc) heus wel wist dat het niet zo’n vaart liep. Maar die vinden zoiets juist prima: Een waterdicht excuus om meer geld uit te geven dus te factureren. Als het goed afloopt kunnen ze zeggen: Ja, het kostte wat, maar veiligheid boven alles! En daar gaat niemand tegenin.

Als je een beetje kennis van zaken hebt, maakt het minder indruk. Veel systemen doen sowieso niets met datums. Vrijwel altijd zijn er hele generaties apparaten met hetzelfde probleem en komt er gewoon een update. In het ergste geval, zoals die parkeermeters, ben je een tijd aan het updaten. Dat kan steeds vaker gewoon op afstand.
Ik hoop dat je ook de overgang van 31-dec-2000 -> 1-jan-2001 getest hebt want op dat moment ging er juist van alles mis in firmware... (met name als een systeem over de overgang uit stond...)
shutdown in 2000 en boot in 2001.. niet getest... dan heb je maar half werk geleverd.
Nou, veel bedrijven hebben destijds tot het laatste moment gewacht. De Y2K bug was al jaren van te voren bekend, toch werden veel bedrijven pas op 31 december 1999 ongerust en moest hals over de kop de boel aangepast worden. En daar hebben veel mensen van geprofiteerd ja. Dat kan prima benoemd worden.
Nou...bepaalde leveranciers hebben ook erg geprofiteerd van een probleem waar zij zelf voor verantwoordelijk waren. Ik ga geen namen noemen, maar ik weet dat er leveranciers waren die de Y2K controle van hun (door deze leverancier gemaakt dus) programmatuur liet betalen. Deden ze deze controle niet, verviel de aansprakelijkheid. Ik vond dat nogal wat. Jij levert iets dat dus niet deugt en het herstel mag de klant zelf betalen, anders mag ie ook op eigen kosten de gevolgen repareren. Zo'n beetje wat de banken deden met hun rommelhypotheken...

Wat is de commercie toch mooi. Echt een business voor mensen zonder geweten.
Er moest toen ontzettend veel werk verricht worden om alles goed te laten lopen. Je doet nu net alsof het uitblijven van problemen bewijst dat het werk niet nodig was. Dat de aanpassingen veel meer geld gekost had dan dat het nodig was, tjah, dat was een kwestie van vraag en aanbod. De vraag was gigantisch groot, het aanbod soms enorm gebrekkig (COBOL).
Even ter verduidelijking. Al het werk dat (niet) door de vendor werd gedaan gaat en ging via de gebruikelijke kanalen, de service verlenende bedrijven, jawel, ons engineers. *Alle* updates die (niet) kwamen, hard- en software verliepen via onze handen. Ik doe dus niet alsof, maar baseer mijn mening op feiten, jij de jouwe op aannames.

Ik blijf dus bij mijn stelling dat Y2K enorm opgeblazen was (probeer voor jezelf even voor te stellen hoe groot de koopvaardij vloot is wereldwijd), in dit geval.
Dat het in jullie industrie een loos alarm bleek, hoe groot ook, impliceert nog niet dat het in de rest van de wereld zo was. Dus ja, ook jij doet nog steeds aannames op basis van N=1.

En stel zelf nou eens even voor wat er was gebeurd als er niemand op standby stond en allerlei systemen begonnen te falen?

[Reactie gewijzigd door .oisyn op 9 januari 2020 17:10]

" in dit geval.". Ik stel nergens dat dit voor alles en iedereen het geval was. Dus nee, ik doe geen aannames op basis van wat dan ook.

"En stel zelf nou eens even voor wat er was gebeurd als er niemand op standby stond en allerlei systemen begonnen te falen?"

Als de hemel valt zijn we allemaal dood.

Zakkenvullerij dus, in dit geval.
Wat zullen ze gedaan hebben? intern de tijd terug gezet hebben naar 1 jan 2000? we weten dat het werkt op 1 jan 2000 en het is de goedkoopste oplossing... Tot over 20 jaar maar weer :P

oh, eerst nog zien wat er gaat gebeuren in 2038 https://en.wikipedia.org/wiki/Year_2038_problem
Nee, want het moet op 1 janauari dezelfde dag zijn.
1 jan 2000 zaterdag
1 jan 2020 woensdag

Dan gaan je parkeertarieven niet kloppen.
Dat was het advies bij oude videorecorders destijds, het jaartal op 1994 1972 zetten zodat 1 januari ook op een zaterdag valt, wat tevens net als 2000 een schrikkeljaar is.

.edit: in mijn herinnering was het ook iets met de jaren 70 maar ik volgde even niet waarom precies dat decennium. Schrikkeldag was ik idd vergeten, bedankt @Zer0 :)

[Reactie gewijzigd door .oisyn op 9 januari 2020 12:49]

Slecht advies, 2000 was een schrikkeljaar, 1994 niet, na 28 februari liep het dan toch mis....
Videorecorders uit 1972 hadden een mechanische klok zonder datum, en modernere videorecorders kon je meestal niet terugzetten tot vóór de ontwerpdatum van de firmware. Je moest de datum dus nogmaals opnieuw instellen op 1 maart.

[Reactie gewijzigd door mae-t.net op 9 januari 2020 13:20]

Maar dan heb je het probleem dat 2000 geen schrikkeljaar is, waar 1996 dat dan weer wel is. Het lost in ieder geval niet lang de problemen op.
2000 is OOK een schrikkeljaar omdat het deelbaar is door 400. 1900 is geen schrikkeljaar, 2100 ook niet.
Feitelijk zijn er 14 kalenders (7 dagen van de week op 1 januari met en zonder schrikkeldag) en die kalenders rouleren in een cyclus van 28 jaar. Dat is waar de eeuwig durende kalender kaartjes op gebaseerd zijn. (t/m 2099 dan)

[Reactie gewijzigd door tweaknico op 9 januari 2020 13:21]

Je zit met betalingsverkeer bezig en ik mag aannemen dat daarvoor de correcte tijd moet meegegeven worden.
Precies, in 2038 heb ik (ook nog steeds) volop werk :)
Ik denk dat dan een AI dat in 1 nanoseconde voor je hele codebase fixed.
Plus alle andere fouten die je hebt gemaakt ;)
Hmm, voor zover ik weet was het vooral een opgeklopte media hype om de, door de geklapte dotcom bubble in zwaar weer verkerende IT sector wat werk toe te schuiven.
Maar hey, misschien zijn we inderdaad gered door de heldhaftige programmeurs die de boel op tijd hebben herschreven en was onze beschaving anders vergaan.
Euhm ... nee. Zoals in het artikel staat waren er dus enorm veel programmas die een jaartal met 2 cijfers opsloegen en zelfs vandaag achtervolgd dat probleem ons nog. Waarom zou het dan een hype zijn als je er 20 jaar later nog last van hebt? Dan lijkt het mij toch echt om een reëel probleem te gaan.

Was onze beschaving vergaan? Neen. Maar zou jij op intensieve zorgen willen liggen wanneer de apparatuur die je in leven houd niet eens getest is of deze blijft werken in het nieuwe millenium?
Waarom zou je daar apparatuur hebben die datum gerelateerd werkt? Om zon- en feestdagen aan te kunnen geven?
Monitoring is een ander verhaal, maar die functionaliteit moet je niet in één en hetzelfde apparaat willen hebben. Om bovengenoemde reden (minder functionaliteit in kritische apparatuur = minder kans op fouten).
Zo'n apparaat weet natuurlijk niet wie in de scanner ligt, geeft alleen aan wanneer een scan is gedaan en de resultaten. Zal dit zelf ook niet opslaan, zeg dat het in een database terecht komt. Neem nou aan dat de meeste medische scans best groot zijn (meerdere honderden gigabytes is niet zeldzaam), en je ziet al snel een noodzaak oude (irrelevante) data weg te gooien. Als het systeem nou zo ingesteld is om data >80 jaar oud weg te gooien (zeg maar wat), en door de millennium bug denkt het systeem opeens dat de fotos 100 jaar geleden zijn gemaakt, poef, weg data.
Omdat bijna alle "slimme" apperaten logs moeten kunnen maken. Een systeem moet aan kunnen geven dat bv op xx:xx op xx-xx-xx iets aan de hand is. Een hartpomp zou bijvoorbeeld een log moeten maken dat op 22:35 op 25-01-2016 gasbubbles gedetecteerd zijn. Of een zuurstofapperaat zou moeten aangeven dat op 23-06-2017 een corrupte bit gedetecteerd is. (Ik zeg maar wat)

Als de tijd dan verkeerd staat denkt b.v die hardpomp dat -9583 uur geleden dat er gasbellen gedetecteerd zijn. En dat snapt die hartpomp dan niet en er komt een bufferunderflow. Tja en dan gaat ie uit.

[Reactie gewijzigd door rickboy333 op 9 januari 2020 12:05]

Zowat elk digitaal apparaat werkt intern met tijd. Al was het maar om logs weg te schrijven. Als er dan fouten in de software zitten waardoor de klok van 19991231235900 naar 19000101000000 gaat terwijl het systeem 100 jaar later verwacht, dan zou er wel eens het een en ander kunnen crashen in de achtergrond die heel je systeem neerhaalt. En dan zitten we gewoon nog maar op basisniveau te kijken zonder naar de specifieke werking van toestellen.
Er is in die tijd inderdaad enorm veel werk verzet. Achteraf zeuren dat er toch niets gebeurd is, vind ik een beetje goedkoop. Net als afgelopen oudjaar, waar er geen rellen waren in Duindorp. Was dat door de aanwezigheid van de ME of omdat de bewoners toch niet zo asociaal zijn als we dachten? Wie zal het zeggen? We kunnen niet 2x hetzelfde evenement proberen, 1x mét en 1x zonder ME.
Feit is dat er zelfs speciaal mensen (niet ICT'ers zelfs) zijn opgeleid om bepaalde zaken in programma's te corrigeren. Zonder die inspanningen zou er toch echt een hoop ellende zijn geweest. Of de wereld tot stilstand zou komen weet ik niet, maar dat veel programma's en systemen tot stilstand zouden komen is wel duidelijk. Dat is ook gedemonstreerd dmv tijdreizen (klok vooruit zetten).

Ik heb ook bij een aantal klanten wat werk verricht. Gelukkig viel de schade mee, maar evengoed hadden we in 1 rapport iets over het hoofd gezien dat eind februari 2000 de kop op stak (omdat 2000 toch een schrikkeljaar was) en het rapport dus borkte met een melding dat er een ongeldige datum gebruikt was. Gelukkig alleen maar een rapport en geen ILS systeem van een vliegtuig :+
Idem wat je nu vaak hoort over klimaatverandering. "Over dat gat in de ozonlaag en de zure regen werd ook moord en brand geschreeuwd, maar daar hoor je nu niks meer over, dus die klimaatverandering zal ook wel overwaaien."

Ja, leuk gedacht, maar die twee andere problemen zijn a) veel eenvoudiger op te lossen en b) alleen maar gereduceerd tot beheersbare proporties door intensieve internationale samenwerking en daadwerkelijke, ingrijpende maatregelen. Dus dat je daar niks meer van hoort wil niet zeggen dat we nu op onze handen kunnen gaan zitten voor de klimaatverandering.
Maar de dotcom-bubble klapte pas in 2000, een hele tijd na de paniek om de millenniumbug.
Ik heb op Twitter en Reddit genoeg verhalen gelezen van developers die in de periode voorafgaand aan 2000 toch echt met grote teams hard hebben moeten werken om het te voorkomen
Dat was het zeer zeker niet. Echt heel veel systemen moesten aangepast worden. Sterker nog, er waren ook echt zo veel mensen nodig. Ik weet nog dat er zelfs studenten uit het laatste jaar uit de schoolbanken gehaald werden om te komen werken voor bedrijven, omdat er te weinig programmeurs waren. Deze kregen aanbod om een jaar te komen werken tegen mooie salarissen en ook werden dan de studiekosten voor het laatste jaar betaald als ze weer verder gingen studeren.

Zeker in de banksector waren er veel systemen die verkeerde berekeningen uit gingen voeren doordat ze niet met 2000 om konden gaan en zouden gaan rekenen met het jaar 1900.
We hoeven niet tot 2099 te wachten.
De eerstvolgende millenniumbug is op 19 januari 2038 om 03:14:07 UTC.
Dat is dan geen millennium bug hé. En 2099 overigens ook niet. Het jaar 1000, 2000, 3000 dat zijn millennia.
Dat hangt er vanaf hoe je telt. Ik vind 0x80000000 wel een millennium.
Jij vindt 2147483648 een periode van 1000 jaar?
Oke, tijdperkbug dan.
"De meeste experts vermoeden dat veel programmeurs in 1999 de jaartallen lieten doortellen tot '20, in plaats van tot 2099 of nog langer."

Het issue was toch dat men de eerste twee digits van het jaartal in code achterwege liet? Daardoor werd 2000 gezien als 1900. Als je jaartallen 'door laat tellen tot 20' los je daarmee het probleem inderdaad niet op. Dan heeft men daarin ook af moeten vangen dat alle getallen van 00 tot 20 niet met prefix '19' moeten werken maar met '20'. Dat is een tijdelijk lapmiddel.

Waarschijnlijk was dat makkelijker dan de lengte van het veld aanpassen zodat het hele jaartal erin past. Dat moet je met de database aan de slag en het beeld dat ik heb van databasebeheerders is nou niet echt dat dat de meest flexibele personen zijn ;-) ...en de code die daar omheen zit moet uiteraard ook aangepast worden.

Dus in plaats van een oplossing voor lange(re) termijn is ook hier weer gekozen voor de 'quick' fix.
Rustig aan he over database beheerders ;)
Snap het wel. De tijd van databases zag er toen ook wel wat anders uit

Ik merk tegenwoordig dat het steeds vaker andersom is: vanuit de datalaag signalen geven dat zaken ook beter kunnen worden opgelos en meedenken ipv blind uitvoeren. Dus we zijn al wat flexibeler geworden :)

Hetzelfde kan gezegt worden van de Euro implementaties en conversies vanaf de gulden.

Regelmatig zie ik misbruik maken van datatypes voorbij komen.
Databases waren het probleem niet. ADABAS date en time formats komen pas rond 2700 in de problemen, en dan heeft de mensheid zich al lang uitgeroeid, hetzij door een 3e wereld oorlog, hetzij door de krankzinnige overbevolking en de daaruit voortvloeiende problemen. Het probleem zat toen in de sequentiele en Vsam bestanden, en uiteraard de bijbehorende sorts e.d. Je kunt niet zomaar in da soort bestanden de datum 8 logische posities geven (ongeacht het formaat) aangezien dan sorts niet meer kloppen. Ik denk dat Kastosti de wereld, zoals vaak hier op Tweakers, bekijkt vanuit Servers/Pc's, en niet vanuit Mainframes, waar zeker toen 'alles' op draaide (en nog steeds veel), met de bijbehorende programmeertalen: Assember, Cobol, PL/1 en Natural (en RPG en ... ).
Klopt, de mainframe wereld is er niet eentje die ik heel goed ken. De term wel van vroeger, toen mijn pa nog in de IT zat, maar vandaag de dag hoor ik de term niet meer.

Dat je niet zomaar een format aan kunt passen snap ik, maar dat is niet anders dan op een willekeurig ander systeem. Je moet direct rekening houden met alle afhankelijkheden, zoals inderdaad sorts.

Het oplossen, of in dit geval verschuiven, van het issue heeft toch ook redelijk wat tijd en geld gekost. Was het dan achteraf gezien (want dat is lekker makkelijk praten) niet toch beter geweest om te gaan voor een echte oplossing?
In Windows was tot voor kort ook de range 1930 - 2029 voor double digit years.
Pas sinds de 1909 update is dat veranderd in 1950 - 2049.
Maar dan heb je het over menselijke input. Tja, als je maar 2 cijfers invoert dan zul je toch iets moeten verzinnen, dat is in beginsel gewoon ambigu. Al heb ik wel het idee dat we in deze eeuw veel minder vaak de 2-digit jaarnotatie gebruiken dan eind vorige eeuw :)

[Reactie gewijzigd door .oisyn op 9 januari 2020 17:16]

Als ik dit lees voel ik me oud. Milleniumbugs voelen niet als 20 jaar geleden :X


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True