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
×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste prijsvergelijker en beste community. Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers!

Japanse aftredende keizer kan soort millenniumbug veroorzaken

De abdicatie van toenmalig koningin Beatrix verliep in 2013 zonder grote problemen, maar dat is volgend jaar wellicht anders als de Japanse keizer aftreedt. De Japanse kalender verandert met een nieuwe keizer en dat kan computers laten crashen, als ware het een millenniumbug.

De Japanse keizer Akihito kwam in 1989 op de troon te zitten, maar zal op 30 april 2019 definitief plaatsmaken voor de 57-jarige prins Naruhito. Deze feestelijke gebeurtenis kan volgens een analist leiden tot crashende computers van Japanse overheden, postkantoren en banken.

Dat heeft te maken met de Japanse kalender, die is gebaseerd op de tijdperken die worden gemarkeerd door de zittende keizer. Akihito werd in 1989 keizer en dat ging gepaard met het begin van de Heisei-era. Verreweg de meeste hedendaagse in Japan gebruikte systemen en computers stammen uit dit tijdperk en zijn dus nooit getest op wat er gebeurt als er een nieuwe era begint.

De overheid zal op 24 februari 2019 de naam van het nieuwe tijdperk aankondigden. Microsoft bevestigde eerder al dat de meeste software niet getest is op hoe wordt omgegaan met een nieuwe era en dat de gevolgen vergelijkbaar kunnen zijn met die van de millenniumbug.

Om problemen te voorkomen, heeft Microsoft in de Windows 10 Spring Creators Update een placeholder in het register opgenomen, zodat gebruikers softwarebeperkingen rondom het nieuwe tijdperk kunnen ontdekken. Eventueel kan de waarde in het register worden aangepast of verwijderd als zich problemen voordoen.

Er kunnen bijvoorbeeld problemen ontstaan als de kalender het niet toelaat om te navigeren naar een vorige era en ervan uitgaat dat er slechts een era is: de huidige. Ook kunnen programma's toekomstige data hebben opgeslagen op basis van de huidige Heisei-era, terwijl die data in de nieuwe era zullen vallen. Dat kan bepaalde algoritmes in de war brengen.

Door Joris Jansen

Nieuwsredacteur

24-07-2018 • 16:44

146 Linkedin Google+

Reacties (146)

Wijzig sortering
Als die kalender in Japan echt zo variabel is lijkt het mij dat een beetje programmeur daar dan rekening mee houd? Is dit niet een beetje paniekvoetbal van een enthousiaste journalist.
Het programeren van de tijd/datum systemen op de wereld, is een uiterst complex stukje techniek, bijna niet leuk meer.

https://www.youtube.com/watch?v=-5wpm-gesOY

@SinergyX De milleniumbug is voorkomen omdat er vele tienduizenden ITers de jaren ervoor bergen werk verzet hebben om dit te voorkomen. Want problemen waren er zeker. Zonder al die werkzaamheden van deze stille helden... zou de IT wereld daadwerkelijk de puinhoop in storten waar voor gewaarschuwd was.

Vliegtuigen zouden niet uit de lucht vallen, maar het banken systeem zou in elkaar storten, de communicatie systemen zouden onderuit klappen.

Het is geen kwestie van "hier even rekening mee houden", we leunden destijds op troep uit de jaren 60,70 en 80. "20 jaar was ver in de toekomst, tegen die tijd kijken we er wel naar", als er uberhaupt enigzinds rekening mee gehouden werd.

leesvoer

[Reactie gewijzigd door batjes op 24 juli 2018 17:51]

Het programeren van de tijd/datum systemen op de wereld, is een uiterst complex stukje techniek, bijna niet leuk meer.
Helemaal mee eens.
Maar dat heeft niet veel te maken met de millenium-bug. Dat was een simpel probleem. Sommige software sloeg het jaar op als 2 digits. Sommige software. Alle software op Unix system slaat de tijd op in seconden sinds 1 Jan 1970. Die software was bv zo goed als niet kwetsbaar.
zou de IT wereld daadwerkelijk de puinhoop in storten waar voor gewaarschuwd was. ... maar het banken systeem zou in elkaar storten, de communicatie systemen zouden onderuit klappen.
Overdrijven is ook een vak.
Banken gebruikten inderdaad hele oude systemen. En ze hadden ook nog systemen geprogrameerd in COBOL. COBOL was een taal die je uitnodigde om inderdaad 2 digits te reserveren voor het jaar.

Communicatie-system die zouden onderuit klappen ? Ik werkte in 1999 voor de grootste leverancier van Internet-apparatuur. Wij hadden geen enkele millenium-related bug in onze software. Voordat we al checkten. Er zat op 31 Dec een klein alarm-team klaar, om in te springen "wanneer de communicatie systemen eruit zouden klappen". Wel, er gebeurde helemaal niks. Niet met onze apparatuur. En ook niet met de andere apparatuur bij onze klanten.

Het millenium-probleem was inderdaad een probleem. En er moesten system worden aangepast, omdat anders sommige system down waren gegaan. Alles moest gecontroleerd worden. Daar is een hoop energie ingestoken. En er is een hoop geld mee verdiend. Maar uiteindelijk liep het met een sisser af. Een hoop hype.

[Reactie gewijzigd door gryz op 24 juli 2018 19:43]

>>Alle software op Unix system slaat de tijd op in seconden sinds 1 Jan 1970.
>> Die software was bv zo goed als niet kwetsbaar.
Maar... What happens on January 19, 2038?
On this date the Unix Time Stamp will cease to work due to a 32-bit overflow. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems which will buy the time stamp a "bit" more time.
Er wordt nu al bergen werk verzet om dit probleem te fixen. Dit wordt gedaan omdat de Linux community zich er van bewust is dat veel apparatuur en systemen die vandaag of de komende jaren worden geinstalleerd, die datum nog kunnen meemaken.

Die ezel stoot zich alvast geen 2 keer...
Het jammere is alleen dat op het moment iedereen dat weer anders doet. Ik werk nu aan software die op drie verschillende processors draait (Arm m0, Arm m4 en x86) de datatypes van de tijd en RTC functies in de bijgeleverde C libraries en drivers variëren nu van: old school 32-bit signed, 32-bit unsigned en 64-bit signed.

Uiteindelijk was de beste oplossing voor ons nu iig om gewoon een eigen libraries en drivers te schrijven waar we de volledige controle over hebben (tijd is nogal belangrijk in safety critical life support systemen).

Daarnaast heb je het probleem dat je software wel een mooie timestamp kan gebruiken, maar veel RTCs (de electronica die de tijd bijhoud) kalender gebaseerd zijn met BCD getallen voor de datum en tijd. Deze slaan gewoon maar 2 cijfers voor het jaar op en dus ben je alsnog terug bij af.

[Reactie gewijzigd door jmzeeman op 25 juli 2018 08:56]

No offense, maar als je in 2038 nog 32-bit systemen gebruikt verdien je het om er uit te klappen. Die worden tegen 2038 al zo’n 25 jaar niet meer gemaakt en waren dus allang al aan vervanging toe. Een storm in een glas water dus.
Het systeem zelf hoeft niet per sé 32 bit te zijn. Als je timestamps slechts 32 bit groot zijn, heb je een probleem.

Een voorbeeld is een zuinige/goedkope IoT-microcontroller die werkt met 32-bit timestamps terwijl je server deze in tekstvorm uitleest als 64-bits, denkend dat er niets aan de hand is.
- De software zal niet crashen, maar kan afhankelijk van de implementatie nieuw gegenereerde data negeren, denkend dat deze ouder is dan vorige records.
- De sturingssoftware kan in een request loop belanden die wacht tot de nieuwste request nieuwer is dan de vorige (maar nee, hij is 68 jaar ouder).
- ..

In het beste geval komt eenmalig Δt ≈ -2^32 voor in je berekeningen en zorgt het voor een zeer korte uitschieter in je meetresultaten/output.
64bit OS kan nog makkelijk een 32bits applicatie draaien. Op het werk hebben we software welke al 15 jaar niet meer is gewijzigd ivm een nieuwere applicatie. Toch willen klanten soms puur een hardware upgrade met dezelfde oude proven technology software.

Niet alle software is ontwikkeld om 200 jaar mee te gaan, en soms wordt je dan achterhaald door de lange toepasbaarheid van een correct werkende applicatie, welke nog precies doet wat de klant vraagt.

Adobe lost dit op door een abonnement af te sluiten op hun software, en dan moet je wel upgraden. Dan heb je deze problemen niet. Maar ook daar zijn niet alle gebruikers even goed over te spreken. Je doet het niet vaak goed..
Los van het feit dat de meeste desktop/mobile OSen tegenwoordig 64bits zijn, geldt dit natuurlijk niet voor alle andere apparatuur. Al je embedded systemen, allerlei IoT connected apparaten en veel losse modules zoals thermostaat etc of je klok in de oven. Veel oudere ( maar ook zeker huidige en toekomstige ) IoT apparaten draaien ook gewoon op 32bits ARM apparatuur. Dus de UNIX epoch zal daar zeker over gaan miepen.
In 2038 wel hoor. Dan is ook je broodrooster 64-bit ;)
Ja. En hij reageert op de sensor van je bewakingscamera in je slaapkamer, die ziet dat je wakker wordt. Probleem is alleen dat de 'praten' via een hub van een fabrikant die uit pure gemakzucht een oud stukje 32-bit software is blijven recyclen. Pas nadat jij jouw hub hebt gekocht is deze fabrikant wakker geschud en heeft hij alle voorgaande versies tot EOL gebombardeerd en worden deze niet meer ondersteund. Maar dat is volledig langs jou heen gegaan, omdat jij dacht dat dat allemaal wel p tijd gefixt zou worden.

Dus de vraag is, hoe gaat jouw broodrooster om met de mededeling dat jij 68 jaar geleden bent opgestaan?
Genoeg simpele systemen die oude computers gebruiken.
't is alweer lang geleden maar toen ik zelf nog bij de overheid gedetacheerd was moest ik de computers op de werkplekken upgraden maar sommige systemen werd niks mee gedaan omdat 't goed werkte en er geen upgrades beschikbaar waren.
De computers waar de paspoorten op aangemaakt worden bijv draaiden toen nog op DOS. terwijl de rest inmiddels op Windows XP draaiden.
Die paspoortcomputer is nooit een Windows programma voor gekomen destijds, het functioneerde prima onder DOS.

Voordeel van zo'n oud systeem is ook dat alle software en hardware bugs wel zo'n beetje bekend zijn en dat je daar omheen kan werken, daarom had de Space Shuttle destijds ook nog 386 processors aan boord voor de besturing, daar mocht niets mee fout gaan.
Vergeet niet hoe snel de IT-wereld in 25 jaar verandert. 25 jaar geleden hadden we nog niet eens Windows XP (volgens mij toen win3.11?), en als je nu nog XP draait verdien je ook geen stabiele systemen...
Ja, sommige bedrijven gaan heel langzaam vooruit, maar 25 jaar is een hoop tijd om systemen te vervangen.
Ik moest enorm lachen. Vijfentwintig jaar geleden zouden we nog op Windows 3.11 zitten. Windows 3.11 is prehistorisch! Dat hadden mijn ouders nog net meegemaakt dacht ik.
En toen checkte ik https://en.wikipedia.org/...icrosoft_Windows_versions
Windows 3.11 release date 1992

Ik ben zelf al prehistorisch.
En toch, die paspoortcomputers hebben ze een paar jaar terug pas geupdate, vooral omdat paspoorten (en rijbewijzen) nu simpele pasjes zijn met biometrische "beveiliging" (vingerafdruk en gezichtscanning)
Het is vooral door het veranderen van het paspoort zelf dat die systemen verouderd zijn geworden, niet door de software of hardware.

Overigens zijn er sinds de upgrade wel problemen met beveiliging, de nieuwe systemen hangen aan internet want dan kan de boel real-time verwerkt worden.
De oude systemen waren stand-alone machines die dagelijks een externe database update kregen.
Oude cpu's in de ruimtevaart zijn idd gebruikelijk, maar niet alleen omdat het nou eenmaal goed werkt. Nieuwere chips zijn veel gevoeliger voor straling doordat ze op een kleiner procedé gemaakt zijn.
ook omdat ze geen uitgebreide functionaliteit nodig hebben, hoe minder overbodige functionaliteit, hoe betrouwbaarder en voorspelbaarder het is
DCS en PLC systemen gebruiken ook vaak die Unix klok. En reken er maar op dat er nog zat systemen die nu geplaatst worden over 20 jaar nog draaien.

Aanpassen in ee. Nieuwe versie is niet zomaar te doen, je zit met backwards compatibility
Ik reageerde in eerste instantie direct op ed vertijsment en ging daarna in op sinergyx.

Maar het is niet alsof het er niets mee te maken heeft. De Y2K bug is de eerste keer dat we juist met onze datum/tijd systemen enorm in de knel zouden komen.

En lang niet alle Linux software slaat tijd op in Linux tijd maar converten het gewoon vanuit timestamps.

Ik haalde verder voorbeelden aan uit het Reddit topic, er zijn best wel wat grote banken, elektriciteits netwerken en een grote Amerikaanse telecom provider die serieus in de nesten zouden komen.

Lang niet elk bedrijf of land had er evenveel last van. Er draaide destijds nog een boel legacy shit uit het jaar kruik toen 2000 ver weg was en bij niemand uberhaupt opkwam en vergeet niet de enorme hoeveelheid prutswerk wat her en der ontwikkeld en gebruikt wordt.

Het liep met een sisser af dankzij de media campagne, zonder die angst was er nooit de daadkracht geweest om management e.d. over te halen dat hun systeem serieus gevaar liep (als men het al door had).
Waarom zou COBOL je uitnodigen om slechts 2 digits te gebruiken voor het jaar... 4 of 2 digits is even vanzelfsprekend in COBOL. Het verhaaltje van storage gaat volgens mij al evenmin op (2 digits extra is in packed formaat slechts 1 byte)... de gebruikers waren gewoon te lui om steeds "19" te typen en daarom heeft men dit destijds nooit opgenomen als 4 digits.
Cobol was een taal die gebouwd was rondom zgn. "records". Records zijn een soort data-structuren. Meerdere velden binnen een logisch ding. Die records leven niet alleen in RAM, maar ook op disk. In Cobol moet je definieren hoe je records er uitzien. Van wat ik me kan herinneren, waren er bepaalde voor-gedefineerde velden die je in je record kon gebruiken. En een twee-cijfering jaartal was zo'n standaard veld-type in een record.

Vergeet niet, midden jaren tachtig draaiden er nog een hoop professionele systemen met disks van 100-500 MB. Als je dan tienduizenden records moet opslaan, dan maken die 2 extra bytes best wat uit. Zeker als je meerdere van die "trucjes" gebruikt.

Ik heb laatst een 6TB disk gekocht. Minder dan 200 euro. Begin jaren tachtig kon je, denk ik, de administratie van meerdere multi-nationals kwijt op een disk van 6TB. Misschien wel de administratie van half Nederland. :) (6 TB zijn 60.000 HDDs van 100MB).

[Reactie gewijzigd door gryz op 25 juli 2018 01:27]

Tienduizend records met een 6 digit datum versus een 8 digit datum is 9 KB verschil !

Eind jaren tachtig toen ik begon op dergelijke systemen was storage trouwens al helemaal geen issue meer, nochtans bleven velen rustig 6 digit dates gebruiken. Het was dus eerder laksheid dan effectief storage gebrek in die periode (meer dan 10 jaar voor het jaar 2000).
En als je maar 64k hebt dan is dat toch een heulboel :+

Ach ons programmeurs was lui denk ik :)
Alle software op Unix system slaat de tijd op in seconden sinds 1 Jan 1970.
Inderdaad, seconden sinds 1970-01-01T00:00:00Z (1 januari, 1970, 00:00 UTC).

Om het nog leuker te maken:
Het probleem met deze definitie is dat op 1 januari 1970 UTC (Universal Time Coordinated) nog niet bestond in z'n huidige vorm.

Datum/tijd heeft slechts een betekenis als er afspraken over gemaakt zijn. Bijv. jaren/maanden/dagen na de geboorte van christus. In feite is dit hetzelfde als POSIX/Unix-tijd: er is een afspraak gemaakt over tijdstip '0', ofwel de Epoch. De datum/tijd is dan de tijd die verstreken is sinds de Epoch.

Omdat de aarde niet in exact 86.400 seconden om z'n as draait dient er zo nu en dan een leap-second (schrikkelseconde) geïntroduceerd te worden in UTC. En je raad het al: in POSIX/Unix-tijd worden deze schrikkelseconden niet mee geteld.

Implementeren van tijd in een computer heeft dus wat meer voeten in de aarde dan je denkt, zeker wanneer er op een van te voren onbekend moment een nieuwe Epoch word vastgesteld (bijv. het tijdstip waarop een nieuwe keizer aantreed).
Dat is het grote probleem van programmeurs en ontwikkelaars.
Kijken en denken zelden vooruit en gebruikers raken opgezadeld met hun troep uit gebrek aan beter.
Ergonomie en gebruiksvriendelijkheid zijn even belangrijk als goed programmeerwerk, meeste ontwikkelaars denken nooit naar de gebruiker toe.
Herinner mij nog steeds wat een ITer mij vertelde over zijn opleiding, zijn prof zei, een luie IT is een goede IT.
Zo min mogelijk werk bezorgd op lange termijn altijd grote problemen en veel werk voor de eindgebruiker.
De tijd van 'helden' is al lang voorbij.
Die tijd van helden is er nog steeds, al zie je door de bomen het bos wellicht niet meer. Maar geloof mij als de echte "helden" er zeker wel zijn!

Overigens, een luie ITer is een goede ITer is mijn mantra. Je kunt het op verschillende manieren intepreteren, maar ik ga bij de volgende; als iets te automatiseren valt, dan doe je dat. Dit bespaart op termijn veel manueel ( en blijkbaar te automatiseren ) werk welke daarmee dus gebruikt kan worden om nuttiger werk te doen.

Daarnaast denk ik dat je een verkeerd beeld hebt van programmeurs, wij willen juist toegevoegde waarde bieden in de software die we schrijven, waarom zouden we anders voor dit beroep hebben gekozen? Dat je allerlei managers hebben die continu voor een dubbeltje op de eerste rij willen zitten is het grote probleem, of een veel te beperkt inzicht vanuit de business om een probleem vast te stellen. Programmeurs denken juist heel erg ver vooruit ( tot in den treure zelfs, wat regelmatig tot te grote complexiteit leidt en daarmee het budget/tijd overschrijdt).

Afijn, ik denk dat je beeld van programmeurs vertekend is. Gebruikers weten ook vaak niet wat ze nu echt willen, een programmeur bouwt dan wat de wens is en dan komt de gebruiker er achter dat dit toch niet echt was wat hij/zij bedoelde. Ondertussen wordt de programmeur op het matje geroepen en ligt het blijkbaar allemaal aan hem..
Volgens mij deelt de meerderheid jouw opvatting over luie ITers. Gelukkig maar want naast de tijdsbesparing waar automatisering vaak om te doen is, reduceer je de kans op fouten door handmatig werk. Dat is nog veel meer waard.
Herinner mij nog steeds wat een ITer mij vertelde over zijn opleiding, zijn prof zei, een luie IT is een goede IT.
Volgens mij heb je z’n woorden verkeerd begrepen dan. Luie IT’ers zijn niet goede IT’ers omdat ze de kantjes er van af lopen. Luie IT’ers hebben geen zin om achteraf saai onderhoud te doen en ontwerpen een systeem zo dat zo weinig mogelijk onderhoud nodig heeft. Dat betekent dus meer werk vooraf doen zodat je er over het gehele traject minder werk aan hebt.

Plus, de simpelste oplossing die het probleem oplost is vaak de beste. Onnodige complexiteit levert ook extra werk, onderhoud en problemen op. Maar: met “simpelste” bedoel ik dus niet per se de *makkelijkste* oplossing, want een snelle hack/workaround is vaak het makkelijkst, maar de simpelste is de oplossing die de meest nette en stabiele situatie oplevert. Die kost ook meestal meer werk dan de quick fix, maar scheelt je later weer werk.
Dit is echt je reinste nonsens. Zoals @batjes aanhaalde het is zeer complex om tijdzones "bij de tijd" te houden, en kan het per dag veranderen.

Daarnaast is het "Een luie IT'er, is een goede IT'er" meer gericht op het gebruiken van functies van wat je vaak gebruikt. Omdat als je deze stap niet doet, je makkelijk een kopieerfout maakt en/of bugs en/of nieuwe features moeilijk er in kan verwerken.

Dus ja het kost meer tijd op de lange termijn, maar meestal is dat door feature uitbreiding of het niet eens verwachten dat iets dergelijks zolang mee zou gaan. Bijvoorbeeld is een computer systeem afschrijven in 20 jaar tijd, redelijk realistisch? Wat dus precies op tijd zou zijn om de 2038-bug te "overleven"
het probleem is juist de laag boven de programmeurs, management.
Of van de managers en verkopers die vinden dat alles snel en goedkoop moet "omdat het allemaal zo'n vaart niet zal lopen".

Ontwikkelaars houden juist graag overal rekening mee, maar in de praktijk wordt daar vaak ivm budget maar een kleine selectie uit gemaakt. Een maand later is de verkoper dat weer vergeten en vraagt hij zich af waarom het product toch niet volledig is geprogrammeerd, want dat komt dan ineens wél goed uit als datgene gebeurd is waar de programmeur al voor heeft gewaarschuwd.

En dat het stukje software dan niet volledig werkt mogen verkopers graag aan andere verkopers vertellen, waardoor de "nerds" weer denigrerend in een hoekje worden geplaatst. Helaas zijn er dan ook nog mensen die dat verkeerd begrijpen/uitleggen en op een forum plaatsen...
De link onderaan is ingekort, hij werkt niet.
Als die kalender in Japan echt zo variabel is lijkt het mij dat een beetje programmeur daar dan rekening mee houd? Is dit niet een beetje paniekvoetbal van een enthousiaste journalist.
Hoe dan ?
Aangezien de ene keizer 100 wordt, en de volgende misschien maar 5 jaar op die troon zit
Je lost het op door de UI te scheiden van de interne representatie. Intern gebruik je ISO 8601, dus YYYY-MM-DD. Extern vertaal je dat met de beste kennis beschikbaar.

En ja, het Japanse systeem is gestoord. De nieuwe periode gaat in op de dag na het overlijden van de keizer. Dus als die om 23:59 overlijdt, dan moet de overheid de volgende ochtend bekend maken dat de datum-notatie veranderd is, te beginnen met de datum van die dag zelf - met een paar uur terugwerkende kracht. De krant die op je deurmat ligt heeft een niet-bestaande datum!
het Japanse systeem is gestoord
Ho ho, rustig aan. Er zijn in de loop van de geschiedenis talloze beschavingen geweest met een kalender in de vorm van "het X-de jaar onder het bestuur van koning / keizer / dictator Y". Wij (zowel in de zin van "moderne westerlingen" als in de zin van "computergebruikers") vinden dat onhandig, maar het heeft duizenden en duizenden jaren prima gewerkt, dus je zou bijna denken dat er ook voordelen zijn. Ik ben geen expert op het gebied van wat die voordelen dan precies zouden zijn; iemand die zijn hele leven lang niet anders gewend is (met andere woorden: iemand die is opgegroeid in Japan) kan je daar vast een veel beter antwoord op geven.

Het echte probleem is dat dit systeem incompatible is met computers, maar om te zeggen dat het systeem daarom "gestoord" is gaat wel erg ver, voor hetzelfde geld vinden ze in Japan dat computers "gestoord" zijn omdat ze hier niet mee om kunnen gaan. Want die krant met een ongeldige datum is helemaal geen probleem; geen enkele mens zal "crashen" als ie dat ziet, maar (vermoedelijk zonder erbij na te hoeven denken) de correcte "vertaling" naar het nieuwe systeem maken.

Oh enne... je weet dat onze kalender heel erg op de Japanse lijkt... behalve dat ie nog meer nadelen heeft? We tellen sinds de geboorte van een belangrijk persoon, in plaats van het moment dat iemand de troon besteigt. Van één van die twee is de exacte datum heel eenvoudig vast te stellen, van de andere moet je achteraf terugtellen (niet dat één van de drie wijzen dusdanig wijs was om even een notitie van de exacte datum te maken; was het niet duidelijk genoeg dat het een belangrijke dag was!?), zodat de kerk tegenwoordig denkt dat Jezus geboren is in (als ik me goed herinner) 32 vóór Christus. 8)7 Van de Japanse keizers staat daarnaast redelijk duidelijk vast dat ze ook echt bestaan hebben; voor zover ik het in kan schatten lijken de meeste historici te denken dat Jezus nooit bestaan heeft. En ons belangrijkste voordeel, dat we per definitie slechts één era hebben? Niet dus, "als het goed is" moet Jezus ooit nog een keer terugkeren op Aarde en het zit er dik in dat wij onze kalender dan "doordraaien" naar "x AD" naar "x APD". Hoeveel computers kunnen daarmee omgaan? Juist ja, geen enkele; Y2K is er niks bij (weten we ook meteen waarom de Wederkomst vlak erna tot de Dag des Oordeels leidt :+ ).

TL;DR: iets meer respect en tolerantie voor andere culturen graag. Dat zij een andere oplossing gevonden hebben dan wij betekent nog niet meteen dat hun oplossing slechter is.
Hte logische systeem is dat je telt vanaf de officiële kroning van de opvolger. Dat is een ceremonie die enoige voorbereidingstijd heeft. Dan kun je dus ook de datum-aanpassing voorbereiden. Het probleem met Japan is dat de dag van overlijden de laatste dag van de kalender-periode is, waardoor je hooguit uren, zoniet minuten de tijd hebt om alle voorbereidingen te doen. Dat gaat dus in de praktijk fout, met als gevolg dat je met terugwerkende kracht data moet aanpassen.

Om een idee te geven: dat is zoiets als op 29 februari belsuiten dat het toch geen schrikkeljaar is, en de huidige datum aan te passen naar 1 maart.

off-topic: we weten van de Romeinen dat er rond het jaar 0 inderdaad mystieke Joodse sektes waren in de regio van Jeruzalem. Waarom één van die sektes de overhand kreeg weten we niet, maar historici hebben weinig moeite met het enkele bestaan van Jezus.
Tja, deze keer is alles vantevoren bekendgemaakt. Dus eigenlijk nog een mazzeltje.

Normaal gesproken sterft de keizer in het zadel. Om de abdicatie van Akihito mogelijk te maken hebben ze zelfs een wetswijziging moeten doorvoeren.

Rare jongens die Romeinen, err.... Japanners. 8)7
<offtopic>
Je hoeft het zo ver niet te zoeken.
Ook bij ons in Belgie is er een akte van abdicatie (aftreden van een levende Koning) opgesteld toen Koning Albert II aftrad, omdat dit niet in de grondwet was opgenomen.

zie : https://nl.wikipedia.org/...ing_in_Belgi%C3%AB_(2013)
<offtopic>

Dus rare jongens die Rome... euh Belgen :)
Nog veel vreemder was dat zijn voorganger tijdelijk is afgetreden omdat hij een wet niet wilde ondertekenen. Vooral dat hij weer terug mocht komen.
Ik snap dat wel, maar op basis van het huidige systeem kan je gewoonweg geen rationele tijdlijn maken.
@Ed Vertijsment zegt dat een programmeur er rekening mee moet houden, alleen is dat voor ons mooi gesproken, maar in een andere tijdsnotatie zul je je aan die regels moeten houden.
Vergeleken met de normale geneuzel omtrend tijdzones, DST en schrikkelsecondes is het bijhouden van tijdstippen waarop jaartelling en naam gereset worden uiterst simpel. En ja, machines die niet geupdate worden hebben het verkeerde jaar/naam. Dat maakt voor de werking helemaal niets uit. Bijkomend voordeel is dat maanden voor zover ik weet geen naam hebben, het is simpel "maand 1", "maand 2", "maand 12".

Overigens als tourist heb ik me nog nooit druk gemaakt om de verschillende jaartellingen en gebruiken alle computers gewoon de standaard C.E. jaartelling. Het probleem zal alleen in heel specifieke software optreden, maar het is dus niet de eerste keer dat men met dat bijltje moet hakken.
Was dat ook niet het geval rond de milleniumbug? Van complete downfall van internet tot terug naar stenentijdperk, en zo ging 01-01-2000 voor 99% ook weer rustig voorbij, om vervolgens eind 2000 weer op te komen omdat er ook nog een '01' bug zou zijn.
Daar vergis je erg sterk in. Veel PC's van voor 1988 ofzo hadden maar een 2 cijferige waarde voor een jaar. En zomaar ''18'' invullen was ongeldig. Gelukkig zijn er na de jaren 80 PC's gemaakt waarmee de tijd in 4 cijfers weergegeven kan worden en de legacy systeem van de overheid ect zijn toen gepatched waardoor er bijna geen problemen waren. De 2038 bug zal een iets groter probleem worden omdat het tijdsysteem in 32 bit geschreven is en legacy systemen niet ''zomaar'' een 64 bit systeem kunnen gebruiken.

Voor japan zal de schade verder ook wel meevallen. De meeste computers daar gebruiken de gewone tijdsverdeling overal op de wereld en ook daar is het 24 juli 2018. Wat kan gebeuren is dat sommige internet applicaties merken dat er een ''onbekende era'' is waardoor ze kunnen vastlopen. Legacy systemen en grote systemen zullen hier amper last van hebben omdat deze fout niet hardwarematig ingebakken zit en het heel simpel te patchen is. Een storm in een glas water dus.
Het zal me verbazen met de huidige staat van vooruitgang in technologie dat in 2038 er nog legacy systemen zullen zijn en dan vooral op 32 bits. Vooral omdat dit al veel eerder bekend is dan de 2001 en deze keizer-bug.

[Reactie gewijzigd door Xfade op 24 juli 2018 18:29]

Het zal je verbazen hoeveel legacy systemen er nog steeds gebruikt worden. Een voorbeeldje is het nucleaire wapensysteem van de Britten!
Britain’s Atomic Weapons Establishment, which maintains that country’s nuclear warheads, use PDP minicomputers manufactured in the 1970s by Digital Equipment Corporation (DEC).
In Frankrijk was er een paar jaar geleden een probleem omdat een PC met Windows 3.1 het niet goed deed.

En wat dacht je van MOCAS. Een antiek systeem uit 1958 dat in het Pentegon alles regelt.

Er zijn meer legacy systemen nog steeds in dienst dan jij denkt. Natuurlijk hangen ze niet (meer) aan het kan nog wel een problemen worden als de Y2036 bug toeslaat.
Oh zeker, ik snap dat op dit moment er zeker nog veel Legacy in gebruik is, dat trek ik ook niet in twijfel.
Ik denk alleen dat vanwege de technologische vooruitgang van nu, er in 2038 weinig mis zal gaan. Mede doordat door dit soort media topics er ook aandacht voor dat soort systemen wordt gecreëerd.
Tussen 1958 en nu is er ook enorme technologische vooruitgang geboekt, misschien wel meer dan tussen nu en 2038. Die systemen draaien ook nog.
Het gaat niet om opslag in databases, het heeft meer te maken met systeemklokken die daadwerkelijk tikken. Dan is het in de eerste plaats erg fijn om op een makkelijke / goedkope manier door te tellen (nu is het gewoon +1, dat is simpel in gates), daarbij is het voor software erg handig om mee te werken: het meeste werk is niet meer dan een starttijd opslaan, en dan die van de huidige tijd af te trekken.

Zelden hoeft een computer te weten welke dag van de maand een tijdstip is, ISO 8601 tijden worden alleen gebruikt om te communiceren met mensen, dus dat komt relatief weinig voor.
Welke malloot verzint dat nou? Joh leuk dat je je datum+tijd notatie in één enkele 32-bit waarde in je database kunt frotten.. levert alleen wél meer rekenwerk op om weer te geven omdat je steeds moet 'tellen' vanaf die startdatum.
Er zijn schrikkeljaren.
Er zijn schrikkelseconden.
Er zijn tijdszones.
Er is zomer-tijd.

De precieze tijd bijhouden is niet makkelijk. Zelfs als je simpelweg van een enkel getal uit kunt gaan (zoals de tijd sinds 1 Jan 1970). Als je de tijd op wilt gaan slaan als een string, dan werkt dat in een file. Maar niet in een programma dat real-time loopt.

Alle klokken (behalve misschien atoomklokken) wijken na een tijdje af. Dat moet gecorrigeerd worden.

Computers moeten een klok hebben. Die moet tot op de milliseconde gelijk lopen. Soms tot op de microseconde. Hoe doe je dat, als je jouw notatie gaat gebruiken ?

De 2038 bug is tegen te tijd dat we in 2038 zitten niet meer relevant. Omdat we *nu al* 64-bit machines hebben. En dus te tijd sinds 1 Jan 1970 makkelijk in een 64-bit waarde kunnen opslaan. Je hoeft je niet druk te maken over een 2038 bug. Slaap lekker.

Ooit echt in het fenomeen tijd gedoken ?

[Reactie gewijzigd door gryz op 24 juli 2018 20:10]

Dat we met 64-bits computers werken is leuk, maar minder relevant. Het gaat erom welk datatype gebruikt is om de tijd op te slaan. Er zal dus wel gepatcht moeten worden voor zover dat niet gebeurd is.
Inderdaad, het gaat erom welk data-type je gebruikt voor je timestamps. En als je oude software draait, dan helpt 64-bits hardware niet veel.

Maar sinds ruim 10 jaar hebben we 64-bit hardware.
En alle OSes draaien 64-bits software.
Er zijn dus geen echte redenen om geen 64-bit timestamps meer te gebruiken.

Ook is het upgraden van software veel makkelijker nu, dan in 1999.
Nu upgraden een hoop machines zichzelf (zoals je hele android systeem).
Of het is een kwestie van een paar klikken.
Ook mogen we hopen dat test-efforts zijn verbeterd.
En dat het dus minder gevaarlijk is om je software te upgraden.
Allemaal factoren die er voor gaan zorgen dat in 2038 er nog maar weinig systemen zijn die software uit 2005 draaien.
Want er zijn dan geen oude Unix bakken meer in gebruik?
Hoe zit het in Android ?
tja, want elk bedrijf heeft slechts desktop computertjes voor zijn personeel. Je bent zeker nooit in de industriele hoek geweest? Daar is XP (helaas) vaak nog redelijk ge-accepteerd. ook kom je nog wel is windows 2000 servers tegen ;).
De echte reden om geen 64-bit timestamps te gebruiken ligt inderdaad in oude (applicatie)software en niet in het OS, dat klopt. Alleen waar haal je vandaan dat software tegenwoordig makkelijker te upgraden of updaten is? Dat geldt voor OS'sen en veel mainstreamapplicaties, maar er zijn meer niet onderhouden dan wel onderhouden applicaties in omloop die soms tientallen jaren meegaan.
Dan heb je het volledige brevet van onvermogen voor ms Excel wel cum laude behaald ook hoor

man man
Geen stress, tegen de tijd dat dit speelt, werken we met 128-bits computers die lachend een 32-bits systeem emuleren. Geheugenruimte zat tegen die tijd.
64 bit is al veel meer dan we ooit op zullen maken, immers 16 exibytes dat is 16.000.000 Terrabyte aan werkgeheugen potentieel werkgeheugen of opslag wat aanspreekbaar is. Dat is heel wat meer als die ~4GB die je met 32bits aan kon spreken :+

128 bit zou dan helemaal onvoorstelbaar veel zijn, en dus niet nodig. De kans dat we ooit 64bit nog vol krijgen is al in het tijdperk dat iedereen een quantum computer heeft, en dan heb je geen 64bits aanduiding meer maar X qbits die geen kwadraat meer zijn.
Klinkt best aannemelijk, maar in de tijd dat geheugen van computers nog in KILObytes werd gemeten, dachten we ook niet dat we een TB aan opslag nodig zouden hebben, of 8-16GB aan memory, dus ik durf daar geen geld op in te zetten

* P_Tingen denkt aan zijn MSX met 23414 bytes free memory...

[Reactie gewijzigd door P_Tingen op 26 juli 2018 12:43]

De millennium-bug van 1999 naar 2000 was wereldwijd en een groter probleem.
Nu heb je het alleen over japan wat maar een land is en niet een internationaal probleem zou kunnen worden.
Veel PC's van voor 1988 ofzo hadden maar een 2 cijferige waarde voor een jaar.
Wut ???!?
De meeste computers daar gebruiken de gewone tijdsverdeling overal op de wereld en ook daar is het 24 juli 2018H30.
Dat kwam ook doordat er enorm veel werk is verzet om alle systemen te checken en fixen. Tegen de tijd dat het 2000 werd waren alle kritieke systemen al gepatched.
Hoeveel moest er echt gepatcht worden dan?
Een hele hoop. Het was zo standaard om het jaar te vermelden met 2 cijfers dat dat serieus tot problemen ging leiden. Een oude dos computer die ik thuis heb staan kan ik niet het jaar "18" invullen want dat is geen geldig jaar. Een hoop systemen met die bugs waren live in de jaren voor 2000.
Eind jaren 99 draaiden de meest werk plekken al een Windows versie.

Men was bang voor embedded systemen, legacy servers en mainframes en programma die systeem gebruikten ipv OS tijd.

Uiteindelijk was het een storm in een glas water.
Storm in een glas water? Zo absoluut niet dus. Banken, verzekeraars en pensioenbedrijven hadden enorm veel werk te verrichten.
In de jaren ervoor zijn (semi) overheid en financiele sector bezig geweest met uitrollen van werkplek automatisering met als piek 1998/1999 je kunt dat waarschijnlijk zien door Compaq verkoopstatitoeken tussen 1995 en 2005 te pakken. Wat je ook zult op merken dat afschriving van 3 tot 5 jaar er ook zult zien.

Met betrekking millennium bug.
Voor werkplek automatisering in combinatie van LAN (Novell/Banyan Vines/Microsoft Server) hadden veel bedrijven en overheden (ministeries) vaak helemaal niets. Met Windows 95 kwam pas de hele werkplek automatisering hype met "floating profiles" men moest toen nut en noodzaak van applicaties beoordelen als ook compatibiliteit en 1 van de test onderdelen was datum (Windows 95/98 Op datum toekomst zetten en testen of applicaties functioneel zonder problemen werkt).

Probleem voor meeste systemen bestond al niet meer.

Alleen legacy spul waarbij systeem datum werd gebruikt vormden een risico omdat ivm kosten van geheugen in het verleden er geen volledige jaartal werd opgeslagen.

Mainframes en andere oude spullen (mini's) hadden dat probleem. Aangezien deze systemen vele vierkante meters nodig hadden en soms zelfs waterkoeling hadden waren ze al deels vervangen dan wel qua hardware dan wel software naar een ander platform.

Het enige risico vormden embedded systemen (plc's, controllers etc...) immers als in datacentrum van overheid zuurstof verdwijnt omdat door bug autobrand systeem gas er in spuit is het lullig dat er een beheerder voor niets sterft.

Ps: inventarisatie en migratie voorbereiding bij die branches deed ik in die tijd.

[Reactie gewijzigd door totaalgeenhard op 24 juli 2018 18:38]

Het probleem zat ook niet bij het OS van de werkplekken, iedereen was wel over op Windows 95+ - het waren de ladingen applicaties en servers die gefixed moesten worden.
Ik ken meerdere ministeries die tussen 1995 en 1998 pas voor het eerst een werkplek automatisering met een LAN oplossing kreeg.

Daarvoor had je stand alone machines aldanniet met terminal emulatie en workstations voor de zwaardere applicaties.

Alleen legacy shit zoals Cobol was het complexer maar je hoefde dat maar op 1 plek op te lossen.

https://homepages.wmich.edu/~rea/Y2K/FAQ.html
Dat 'legacy spul' draaide wel alle belangrijke zaken.
Banken, verzekeraars, Belastingdienst, Woningcorporaties, Uitzendbureaus, Wehkamp (:+)

Dat desktopcomputers al dan niet overweg konden met de milleniumbug deed helemaal niet terzake. De grote systemen die belangrijke zaken regelden daarentegen...

Simpel voorbeeld: Stel je bent uit 1975, en het is 2000. Dan besluit het systeem dat je leeftijd -75 is. Dat is minder dan 18, dus heb je geen recht op huursubsidie

Overstappen op andere hardware betekent niet dat je code op magische wijze ineens wel rekening houdt met een eeuw overigens.
Porten van miljoenen regels COBOL naar een andere taal is ook niet iets wat zomaar gedaan wordt.
Bewijs maar eens dat je nieuwe code hetzelfde werkt als de bestaande (en en passant de millenium bug oplost).

Het meest frustrerende aan het hele Y2K verhaal (en de Euro conversie!) is dat wij het zo goed opgelost hebben dat er hoegenaamd niets mis ging, en vervolgens iedereen maar vinden "Nou, was dat nou zo'n probleem?" JA, DAT WAS HET Alle tijd en geld dat er in gestoken is, was nodig zodat er geen problemen onstonden.

Als je de prutscode/documentatie van sommige (grote) banken zag, snap je niet dat ze nog bestaan overigens.
Ik kan niet inhoudelijk reageren omdat je een paar organisaties noemt waar ik fysiek rondliep in die tijd, NDA.

Maar zoals ik al aangaf dat het een groot probleem was komt voornamelijk door de hype, FUD erom heen niet door de mensen die er daadwerkelijk bij betrokken waren en de impact weten.

Dat gezegd hebbende er zijn veel grotere problemen geweest en opkomst dan millennium bug, bij diezelfde organisaties.
Het grootste gedeelte van de systemen van de overheid draai(t)(de) op Cobol.

Ik heb ettelijke 100.000-den regels code doorgeploegd om de fouten eruit te halen en te corrigeren als student en met mij vele anderen. Leuk zakcentje aan overgehouden.

Bij de RDW hebben ze me ook laten zien wat er fout kon gaan in een demo toen ze aan het werven waren voor "klopvee"
Ik heb zelf niet zitten rotzooien met code rond 2000, maar heb wel op 1 januari 2000 alle kassa's en pin systemen moeten testen bij de Makro in Amsterdam, dat was toen nog veelal oude meuk. Gelukkig werkte alles, maar zeker de pin betalingsverwerker heeft veel werk mogen verzetten. Daarna jaren bij een bank gewerkt en veel verhalen gehoord over wat er allemaal moest worden doorgelopen.

Het was niet alleen Windows, maar ook zaken als een AS400, oude DOS systemen, etc. Heck, ik hoorde zelfs dat ze de oude taperobots zijn gaan testen... Gezien hoe men meestal om gaat met oude systemen en IT is dat echt wonderbaarlijk effectief gegaan. Maar iedereen zweette bloed, want de hoeveelheid geld die misgelopen kon worden of zelfs kon 'verdampen' was echt enorm. Moet je eens voorstellen dat je weken lang niet kon pinnen bij zowel de bank(automaat) als de winkel, we hebben wel eens pin storingen gehad en dan moest je aan de slag met machtigingen. Dat is echt enorm veel werk!
Het aantal regels code dat daadwerkelijk moest worden aangepast was laag, maar het probleem was dat we niet wisten welke. Alle kritieke software moest worden nagekeken. De meeste van die software was prima, maar in sommige sectoren kun je daar niet op gokken.

Vergeet ook niet dat de software-wereld er toen heel anders uit zag. Er was geen patch & update-cultuur. De meeste software kwam van diskette (de nieuwere software stond op CD, maar de oude software bevatte de problemen) en werd nooit bijgewerkt. Internet bestond wel, maar het was nog niet heel gewoon om al je software van internet te halen. In bepaalde kringen, zoals de Linux-wereld wel, maar dat was toch vrij uitzonderlijk.
Tegenwoordig is het heel normaal om iedere maand, week of dag je systeem te laten updaten, maar dat was toen nog niet. Zeker niet voor de oudere software.
Ook aan de kant van de sotfware-ontwikkelaars was men nog lang niet zo ver als nu, denk aan versiebeheer en code checkers. Het bestond allemaal wel, maar het was toch echt een andere wereld. Zonder universeel internet was het ook veel moeilijker om contact te houden met je klanten en om updates te verspreiden.

Er was dus ontzettend veel werk te verrichten, maar het meeste was vrij onzichtbaar voor de buitenwereld.
Een vriend van mij (die nóg wat ouder is dan ik ;) ) is dus vanwege de milleniumbug alle militaire vliegvelden in NL langs geweest, om data de firmware en eventueel OS van alles dat vliegt te patchen.

Moederbord firmware, cobol software (zoals @Nacht al meldde), energie centrales die via een DOS computer warden aangestuurd, en zo was er echt nog wel wat meer.
Dus ja, er moest nogal wat gepatched worden.

Uiteindelijk is het meeste gewoon op tijd gepatched en waren er nagenoeg geen problemen, maar er zijn nogal wat manuurtjes verbrand met het millennium-bug compliant maken van systemen.
Veel systemen werd "gepatcht" met "windowing" https://en.wikipedia.org/wiki/Date_windowing quick and dirty noodfix, een simpel lapmiddel

Met dit lapmiddel was veel af te vangen, iig tijdelijk, en gezien computerkennis en mogelijkheden ook bij de massa door begon te dringen rond die tijd, gingen ze na de media-aandacht hier heel anders mee om.

Inmiddels zijn de systemen die hiervoor vatbaar waren allang uitgesfaseerd, bank- en transportsectoren, en natuurlijk de semi-overheid draaiden voor de eeuwwisseling gerust op iets wat om een 30 jaar oud systeem "intern" heengebouwd was, en data entry met de hand was toen ook nog normaal, nu met certificaten en uitwisselingsstandaarden is dat niet meer voor te stellen..

[Reactie gewijzigd door mjansen2016 op 24 juli 2018 19:06]

Dat is toch exact wat er in het artikel staat?

Dat eigenlijk in het volledige digitale tijdperk dit nog nooit 'variabel' is geweest en er dus geen reden is geweest hiernaar te kijken of rekening mee te houden.
Zegmaar.... net als de millenium bug dus. Komt pas naar voren als het plaatsvindt, en ze denken 'shit, daar hadden we 30-40 jaar geleden nog niet aan gedacht'.
30-40 Jaar geleden werd er juist wel over nagedacht, elke bit telde. Probleem is dat het daarna wegzakt.
Elke bit telde, dus hield je geen rekening met 2000, of met een nieuwe Japanse Era en het wisselen tusen Era's. Je programmeerde gewoon wat er op dat moment nodig en voldoende was.

[Reactie gewijzigd door walteij op 25 juli 2018 08:31]

Nee, niet voldoende, maar optimaal. Er werd veel meer over probleemstellingen nagedacht, code geoptimaliseerd en trucjes toegepast om geheugen te sparen en programma's sneller te laten draaien.
Dan neem je aan dat alle software in Japan door de Japanners gemaakt is, dit hoeft niet zo te zijn. En dat de developers er rekening mee gehouden hebben. Dat laatste hoeft niet altijd het geval te zijn.

Er zit heeeeel veel in tijd / datum / tijdzones / etc waar je als developer geen rekening mee houdt, dat je denkt, 'oh ja dat hebben we ook nog'. En dat is alleen al in NL zo. Denk alleen al aan zomer / wintertijd.
Moest hier aan denken toen ik je reactie las: https://youtu.be/-5wpm-gesOY
En daarom gebruik je UTC.
Sorry, als je weet dat er meerdere tijdzones zijn waarmee je rekening moet houden, ben je als developer niet veel waard als je intern niet werkt met UTC (ISO 8601 of vergelijkbaar). Overigens, ook als je niet van tevoren weet dat je met meerdere tijdzones werkt, kan het vaak beter zijn om met UTC te werken. Vertalen van UTC kun je dan relatief eenvoudig doen en heb je ook geen last van zomer en wintertijd.
Dit is niet nieuw en zou gewoon standaard moeten zijn, net als gebruik van Unicode...
Hoeft niet aan de developer te liggen.
Meegemaakt dat systemen op maandag of zondag begonnen als begin van de week. Niemand die een uitspraak kon/wilde doen wat het nu had moeten zijn. ISO standaard is geloof ik maandag.
Maar zelfs al gebruik je ISO8601, dan moet je nog altijd je vertaalslag op orde hebben. Als daar fouten gemaakt worden of het systeem is er gewoonweg niet op voorzien dan heb je alsnog bugs en kan je app alsnog crashen. Hé kijk, de backend geeft weer dat we in een onbestaand tijdperk zitten. Leuk dat die backend dat kan, maar de front-end moet het wel kunnen afhandellen.
Ja maar hoe update je die variabele dan bij oudere computers?
Hoe weten oudere computers (die dus geen updates krijgen) dat er een nieuw era ingegaan is?
Die tellen gewoon door in het oude tijdperk. En dat hoeft geen grote problemen te geven, alleen maar ongemak. Maar van zodra je 2 applicaties krijgt die met elkaar moeten communiceren en de ene geeft een id door voor een tijdperk waar de andere geen kennis van heeft, dan kan het mislopen.
Ongemak lijkt mij iets te karig om juridische complicaties te beschrijven aangezien de rechtsgeldigheid van formulieren, paperassen en records samenhangt met de juridische implicaties van een correct ingevulde datum. Uiteraard is er een overlap (volgend jaar mag zowel met 31 Heisei geschreven worden, als 1 Volgendeperiode) dit om te voorkomen dat paperassen die in hetzelfde jaar opgestelt zijn als waarin de Keizer overlijd dan vanaf zijn overlijden (toen de Showa-keizer overleed werd diezelfde avond op televisie door de Grootintendant (of was het de Grootzegelbewaarder) al aangekondigd dat vanaf dan 1 Heisei gold).
Maar een 32 Heisei mag dan niet meer. Maar op zich niet zo erg, want ook al doet iedere IT-manager een "ach, die AVG komt ooit nog wel", ze hebben vanaf de Kroning nog driekwart jaar om te voorkomen dat een systeem 32 Heisei zal noteren. Daarnaast zijn het wel Japanners. ;) Nederlanders zouden dan lekker nog tot december wachten om dan ineens in blinde paniek te geraken en uiteindelijk zitten de developers en de administrators nog op oudjaarsavond op kantoor (been there, done that :| ).
xd oude tijdperk ?
Tja, het is natuurlijk ook niet alsof het in de rest van de wereld een verrassing was dat het jaar 2000 er aan kwam. Vaak wordt software gewoon gemaakt om 'voor nu goed genoeg' te zijn, want de volgende drie deadlines komen er alweer aan.
Maken ze in Japan naast hun eigen kalender niet gewoon gebruik van de Gregoriaanse?
volgens mij is dat vooral omdat de rest van de wereld niet met hun tijdsindeling werkt, dus een praktisch puntje. Ik vermoed zomaar dat zij de gregoriaanse kalender dus vooral zien als een soort 'vertaling' van hun tijd (zonder hun eigen kalender ernaast zal het hun waarschijnlijk vaak helemaal niets zeggen).

Als de japanse kalender dan mis gaat, ga je (als mijn redenering klopt) geen bal hebben aan de gregoriaanse kalender, omdat je maatschappij er simpelweg niet op is ingericht.
Beide kalenders worden gebruikt, vaak ook uitwisselbaar. Ouderen zijn uiteraard veelal gericht op de Japanse, maar men weet heus wel wanneer welk jaar is.
hoe is de maatschappij dan ingericht op dat punt? Elke datum staat overal 2 keer?
Hangt van je publicatie af ;). Vaak staat de Gregoriaanse datum en de Japanse datum tussen haakjes op de krant (of andersom, als je een wat rechtsere krant hebt).
Tegenwoordig wordt het wel steeds meer, maar in het begin van deze eeuw (toen ik voor het eerst naar Japan ging) was een Gregoriaans jaartal in de minderheid. Grofweg gezegd geldt een beetje: des te officieler het is, des te vaker zul je de Japanse datum zien (leuk zo'n formuliertje, waarbij je bij je geboortedatum eerst een dropdown hebt met periode (Meiji, Taisho, Showa, Heisei) en dan een veldje waar je een jaar in moet vullen.. 1981, dat was toch 56 Showa?). Bij gemeentes is de afgelopen paar jaar overigens veel veranderd (iets met een nieuwe ID kaart en basisregistratie die niet-Japanse karakters ondersteund) dus daar mag je kiezen of je Gregoriaans gebruikt (de voorkeur) of Japans.
Ook hangt het vaak vanaf of je iets voor lokaal gebruik publiceert/aankondigt of voor een breder publiek. "Echizen Messenbeurs 2018" of "Wakamiya Shinto schrijn Bierfeesten 30 Heisei", de een verwacht publiek uit het hele land (en busladingen buitenlanders), de ander verwacht enkel parochianen uit het afgelegen boerendorpje in de bergen.
Zoals unclero hieronder ook aangeeft, hoe officiëler, hoe vaker de Japanse notatie wordt gebruikt. Voor mij persoonlijk komt dat erg makkelijk uit gezien ik uit Heisei 1 (na 8 januari 1989) stam. Verder is het inderdaad het publiek; wetenschappelijke duplicaties zijn vooral internationaal georiënteerd.

Een ander leuk weetje is dat men zich ook wel afvraagt in welke era iemand geboren is, zo is Heisei modern, maar klinkt Showa (wat dus letterlijk slechts 1 dag kan verschillen) al veel ouder, als een vorige generatie. Taisho is typisch de tijd van oma en opa. Weer eens wat anders dan hoe wij in tientallen jaren denk, zoals de jaren '60 of '70 :)
Tuurlijk wel. Dat hebben ze in de 19e eeuw al besloten, Westerse kalender en Westers meet systeem. De Japanse kalender wordt niet gebruikt voor dagelijkse doeleinden.
Als dat zelfde inhoud als voor ons in 2000 - gebeurd er dus helemaal niets :+
Als ze even veel werk verzetten om systemen te checken en te patchen heb je gelijk.
Er is in 1999 (bleek achteraf) ontzettend veel tijd verbrand met testen terwijl achteraf bleek dat er niet veel aan de hand was. Er waren behalve wat kapotte websites geen noemenswaardige gevolgen, wat in het artikel wel gesuggereerd wordt.
Ik vermoed dat de Japanners ook uitgebreid zullen testen en patchen waar nodig, maar dat buiten Japan het probleem nihil zal zijn.
Er was niet veel aan de hand omdat er net enorm veel werk is verzet geweest. En je kan dan wel zeggen dat veel software is nagekeken waarin geen fouten bleken te zitten, maar zou jij dat risico durven nemen als je van die software afhankelijk bent voor je inkomsten?
Er is in 1999 (bleek achteraf) ontzettend veel tijd verbrand met testen terwijl achteraf bleek dat er niet veel aan de hand was.
Dat mag ik hopen ja. Dat er in 1999 veel getest is aan systemen, waar niets aan de hand was.
In 1999 beginnen met kijken of je software binnen een jaar misschien onzin uit gaat kramen, is onverantwoordelijk wanneer je meer dan een hobbywebsite beheert. In 1999 zal er vooral heel veel getest zijn om te kijken of al het werk dat in voorgaande jaren is verricht tot het gewenste resultaat hebben geleid.
https://www.reddit.com/r/...he_danger_of_the_y2k_bug/

scroll hier voor de lulz even doorheen. Y2K was een serieus probleem.
Volgens mij zal er niet veel interressants gebeuren:
1. Een oud systeem gaat gewoon verder met wat het aan het doen was, het systeem weet misschien dan wel niet dat er een nieuw era is ingegaan maar de relativiteit aan het verleden veranderd niet.
2. Bij de millenium bug ging het er om dat de waarde van verouderde systeem zou overflowen 99 -> 00 dit zorgde ervoor dat de relatieve tijd niet meer klopte. (Tijd: 00 > 99, Waarde: 00 < 99)
1) nee, totaal niet.

Er is zo ontzettend veel data en alles afhankelijk van de juiste tijd/datum.

Mooi voorbeeldje uit het reddit topic:
I worked on reviewing systems at the software house I worked at. I found a bug that would have deleted all of the pictures in a newspaper's production system .... it was supposed to delete anything that was over 2 weeks old, but would have deleted everything.
Wij hadden deze problemen ook rond 2000, er is ontzettend veel werk verricht om al die problemen te voorkomen.

In 2038 kunnen we nog zo'n probleem tegen gaan komen (alhoewel daar nu al rekening mee gehouden wordt), de 32bit Linux time.

2) Die relatieve tijd is ontzettend belangrijk voor communicatie en data. Het zou geen probleem zijn als elk systeem en service op dezelfde manier deze tijds bugs geimplementeerd hebben. Maar dat is juist het probleem, elk OS doet dit anders, elke applicatie doet dit anders. Iedereen vult zelf zijn manier in. Ik durf te wedden dat er nog genoeg programmeurs zijn die nu 18 als jaartal gebruiken i.p.v. het volledige getal, want easy, lui, dom of tijdsgebrek.
In 2038 kunnen we nog zo'n probleem tegen gaan komen (alhoewel daar nu al rekening mee gehouden wordt), de 32bit Linux time.
Op binair 10000000000000000000000000000000 of decimaal 2147483648 seconden na Unix Epoch inderdaad: Tuesday, January 19, 2038 3:14:08 AM
Ik zet hem in mijn agenda. Mooie reden voor een nerdfeestje.
Kans is klein dat er wat mis gaat. 32bit Linux is nu al bijna dood, laat staan over 20 jaar :P
Ben jij daar zo zeker van? Je wil niet weten hoeveel embedded apparatuur een 32bit SOC heeft ingebouwd. Tegen dat we 20 jaar verder zijn zal die wel grotendeels zijn uitgefaseerd maar als ik vandaag 1 cent zou krijgen voor elk 32bit apparaat dat er nog is moest ik nooit nog werken.
En wat dacht je van Raspberry Pi en Co.
Het zit meer in de gereserveerde ruimte in databases voor het timestamp-veld ;)
Als het veld niet groot genoeg is.......
Helaas is in 64bit linux de glibc time notatie ook nog gewoon 32bits. Dus ook al heb je tegen die tijd een 128bit computer, als het niet gepatched gaat worden heb je er last van.
Als je agenda een 32-bits programma op een Unix-systeem is helpt het niet.
Vorige week toevallig via een medetweaker met de volgende toepasselijke youtube :

https://www.youtube.com/watch?v=-5wpm-gesOY
Ik weet niet waarom je inmiddels op 0 staat, want het is een erg nuttig filmpje. Als ik weer les ga geven in Voortgezet Onderwijs of aan propedeuse studenten dan ga ik dat filmpje zeker inzetten :) Kun je direct uitleggen waarom je heel graag patterns wilt gebruiken...
Vertel... Welke patterns gaan je hier helpen?
Hah, misschien wat vaker iets naar beneden scrollen voor ik zinloos dubbele info rondpost =p
Dit wordt net zo gevaarlijk als de Y2K bug of het einde der tijden volgens de Maya kalender, helemaal niks dus :)
Misschien dat ze dat idiote systeem eindelijk afschaffen (zal wel niet, Japan is gek op dingen die onhandig zijn). Iedereen zit iedere keer alles om te rekenen omdat buiten sommige officiële documenten om alles yyyyymmdd is.
Maar wie ben jij om te bepalen welk systeem idioot is en welke niet?

Ik vind bijvoorbeeld ons systeem met 28/30/31 dagen in 12 maanden en 2 x 12 uur ook hartstikke verwarrend, vreemd, inefficient en onlogisch. En daar ook nog eens proberen 4 x 7 dagen in te passen 8)7

Ik weet dat er logica achter zit, maar die is wat verder te zoeken en niet meteen duidelijk voor bijvoorbeeld een gemiddeld kind van 9.
Een kalendersysteem op basis van het 10 tallig (decimale) systeem zou veel logischer zijn, omdat het decimale stelsel het eerste getallenstelsel is waarmee menig kind als eerst te maken krijgt.

Ik kan mij vergissen, maar is dat niet overal ter wereld zo? En dus logischer. Maar ook hierbij geld dezelfde regel: niet het enige. En de bedoeling van IT is om de mens te dienen, niet andersom. Respecteer dus ieder zijn wensen, en bouw de software daarop.

[Reactie gewijzigd door Mocro_Pimp® op 24 juli 2018 20:21]

Helaas werkt de natuur ons dan tegen. Een dag verdelen in 10 uur van elk 100 minuten, van elk 100 seconden (of meerdere tientallen) is natuurlijk gewoon een kwestie van de dag opnieuw indelen.
Maar hoe wil je een jaar in logische tientallen verdelen én je kalender gelijk laten lopen met de seizoenen?
Het kan zeker, maar moet dat ook? Ook dat is een culturistisch gegeven.

De Joodse kalender is een lunarkalender, die met een schrikkelmaand toch gelijk loopt. Dit moet wel ivm Pesach. De Islamitische kalender is een afgeleide zonder schrikkelmaand. Die loopt dan niet gelijk met de seizoenen. Zo zie je de bekende maand Ramadan nu in de zomer vallen, en over 12 jaar in 2030, ongeveer gelijk met kerst.
Klopt, dat de kalender gelijk loopt met de seizoenen, is gedeeltelijk cultureel bepaald, maar was ook een praktische noodzaak. Het is als landbouwer erg handig wanneer je aan de hand van de kalender kan bepalen wanneer je moet beginnen met zaaien, hooien en oogsten. Dat is ook de reden waarom de Joodse kalender regelmatig wordt gereset.
De Islamitische kalender loopt inderdaad uit de pas, maar dat verschil is jaar op jaar dermate klein dat een landbouwer zich daar op in kan stelen. Daarnaast waren de Arabieren ten tijde van de eerste grote golf van de verspreiding van de Islam nog grotendeels nomaden, voor wie een kalender die synchroon loopt met de seizoenen nog niet zo heel erg belangrijk was.

Er is eigenlijk geen praktische reden waarom we nu niet op een decimale kalender over zouden kunnen stappen. BV. 1.000 dagen per 'jaar', 100 dagen per maand en 10 dagen per week. Dan heb je wel een erg lang jaar, maar met grofweg drie 'oude' jaren per decimaal jaar heb je nog een beetje houvast met oude literatuur en verwijzingen.
Het begin van de astronomische seizoenen kan dan op de kalenders aangegeven worden, net zoals nu bepaalde variabele feestdagen en maanfases. Je moet wel voor lange termijn plannen altijd de kalender in de gaten houden of het seizoen wel bij je plannen past.
bedoel je niet mmddyyyy? Of waarom niet ddmmyyyy? En is het hh of HH? Er is simpelweg niet 1 standaard die overal in de wereld gevolgd wordt. Waarom zouden de Japanners dan niet hun ding mogen doen? Het gebruik is eeuwen oud, waarom zomaar afschaffen? Je kan de vraag zelfs verder drijven, waarom spreken wij nog Nederlands? Waarom zitten we niet met zen allen in dezelfde tijdzone? Waarom rijden we niet met zen allen aan dezelfde kant van de weg?
Nee, hij bedoelt echt yyyymmdd. Dat is de schappelijkste manier van datumnotatie maar voor zover ik weet alleen de officiële standaard in Japan.

Daarentegen ben ik het weer met jou eens dat er principieel niets mis is met een era-gebaseerd datumsysteem. Toch zeker niet zo erg mis dat iemand zichzelf het idioot noemt.

Eigenlijk is er wel 1 wereldwijd systeem: seconden sinds epoch... En dat crasht in 2038 ;)

Om met Zen allen aan dezelfde kant van de weg te rijden, lijkt me een typisch Oosterse oplossing trouwens, ook niet voor iedereen weggelegd :9

[Reactie gewijzigd door mae-t.net op 25 juli 2018 01:36]

In Hongarije is yyyymmdd ook de officiële standaard :)
yyyy Is natuurlijk ook vragen om problemen, straks komt er een positie bij.
Dan kijken we eerst hoe de computers in Israel het doen op hun jaartelling, dan hebben we nog een paar duizend jaar de tijd om ze hier te fixen :9
*edit* verkeerde tabblad.

Zullen er vast wel een oplossing voor vinden. Nieuwe keizer gewoon met een update invoeren.

[Reactie gewijzigd door Technomania op 24 juli 2018 17:18]

Tijd is een drama voor devs. Tijd terug een briljant filmpje hierover gezien. Verschikkelijk complex. Zeker met dit soort aparte situaties
Tellen de pc's e.d. daar niet gewoon rustig door? Het is niet zo dat de pc's weten wanneer een keizer aftreed en een nieuwe aantreed. Of is de heerschap een vaste periode? Alle tijd toch om die dingen dan alsnog te patchen lijkt me?

Het is ook wel een erg ouderwetse traditie hoor.
PC Telt wel door, maar maakt contact met andere systemen en dan zit je in het jaar 30, terwijl de rest op nul zit (of zou het 1 zijn?). En dan begint de ellende.

Traditie is waar Japan op draait.
(of zou het 1 zijn?)
Al sterft de Keizer op 31 december, dat jaar is vanaf dan bekend als het 1e jaar van de volgende.
In mijn eerste levensjaar was ik toch echt nul. Maar ik denk dat ze inderdaad bij 1 beginnen, net als de Gregoriaanse telling.
Dat is vooral een perceptie dingetje ;)
"U bent 1 jaar oud" (u wandelt al reeds meer dan 1 jaar op dit aardse tranendal rond)
"Dit is het 1e jaar van huppeldepup" (de periode huppeldepup is minder dan 1 jaar)
Periode + 9 maanden > 1 jaar.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True