EA Sports WRC crasht bij opstarten vermoedelijk door schrikkeldag

De game EA Sports WRC crasht vermoedelijk door de schrikkeldag. Gebruikers kunnen de datum op 1 maart zetten om de game te spelen.

EA raadt spelers aan om de datum te verzetten, omdat er geen andere fix voor het probleem is. Omdat de wijziging in de datum het probleem oplost, lijkt het er sterk op dat de oorzaak ligt in de schrikkeldag. EA erkent dat verder niet. Er is geen patch voor de game. Het is onbekend of de game op 29 februari 2028 speelbaar zal zijn. WRC kwam in november uit.

Reacties (37)

[cricque]

Als programmeur zijnde vraag ik mij af waarom je systeem niet zou werken op een schrikkeldag. Daar moet dan toch extra voor inzitten die iets met die dag doet. Als je zoiets maakt, dan weet je toch dat je hier rekening moet mee houden. Het is niet dat een schrikkeljaar een nieuwe uitvinding is ofzo. Net hetzelfde als systemen die eruit liggen met wijziging van winter en zomeruur. Dat er niemand maar ook niemand aan gedacht heeft dat snap ik echt niet. Het enige wat ik kan bedenken is dat ze de ene of andere library gebruiken waar dit inzit. Enja testen is misschien niet zo gemakkelijk als even de datum op je pc verzetten. Maar je weet dat je om de 4 jaar dit hebt. Maar van kleinsaf aan leer je toch dat om de 4 jaar er eens een schrikkeljaar is ... Dat je niet weet dat als het een veelvoud van 100 is dat het dan deelbaar moet zijn door 400 kan ik nog inkomen, dat wist ik tot een paar jaar geleden ook niet. Maar een schrikkeljaar is toch gewoon algeme basiskennis

[juke1349]

Ik link hierboven een epic fail (met prachtige post mortem) van de Microsoft Azure cloud.

Daar deed iemand "heel simpel" einddatum is jaar-plus-1. Met 29 februari 2013 tot gevolg.. Waar de validatie aan de andere kant op reageerde met "ho eens even".. Waardoor de hele microsoft cloud in safety shutdown ging, omdat "de andere kant" de datacenter work-coordinators waren

Het zit 'm meestal niet in de software die de "simpele" berekening doet, maar in in het feit dat meerdere systemen communiceren, met verschillende aannames/fouten/slordigheden aan beide kanten.

Één van de lessen is dat je datum-Api-design dus niet jaren als rauwe ints moet blootstellen. Waarom Java's en .Net nieuwe time-api dus dingen als "addYear(x)" bieden, en niet "date += 1" (een wat? Milli? Dag? Jaar?)

[Reactie gewijzigd door juke1349 op 24 juli 2024 10:11]

[cricque]

Ik geef nu al 3 jaar een cursus leren programmeren in volwassenen onderwijs en dat is vanaf 0 tot api's en webapplicatie maken. Hiervoor gebruiken we python. Ik heb zelfs een speciaal hoofdstuk opgezet voor datums en problemen daarmee. Ik leg hen ook wel dikwijls verschillen uit tussen anderen talen. Maar voor datums zeg ik altijd, doe dit nooit zelf, gebruikt wat er voor handen is. En daar haal ik dus ook een schrikkeljaar aan en dit nooit zelf te doen. Een maandje bijtellen ... leuk maar de ene maand is 30 en de andere 31, en dan 28 of 29 en 12+1 is nog altijd 13 etc. Dat is gewoon vragen voor problemen. Ook datums uitwisselen via eender welk formaat is nog zo eentje waar veel fouten gebeuren. En met de uurwisseling heb ik ook al genoeg systemen zien falen.

[juke1349]

Falsehoods programmers believe about time: #1 "There are always 24 hours in a day. "
(ik neem aan dat je die lijst al kent, anders list of awesome falsehoods lists, met een hele sectie "time and timezones")

En de chaos als menselijke, sociale systemen in contact komen met computersystemen: overzicht van de aankondiging, en terugtrekking, van de Egyptische zomertijd in 2016
Matt Johnson-Pint: Time Zone Chaos Inevitable in Egypt.

[Verwijderd]

Daarnaast heb je nog daylight saving times, een leapsecond, en greenwitch timezones. Als je terug in de tijd wil, wordt het rekening houden met vanalles.

[Devilscomrade]

Ik kan je zeggen dat C# DateTime.AddDays(1) mij al, klaarblijkelijk, veel leed heeft bespaard.

[lenwar]

aar de validatie aan de andere kant op reageerde met "ho eens even".. Waardoor de hele microsoft cloud in safety shutdown ging, omdat "de andere kant" de datacenter work-coordinators ware

In elk geval fijn dat het beveiligingsmechanisme goed werkte! Je kunt beter stoppen dan in een onveilige situatie doorgaan. Fail secure!

[lenwar]

Als programmeur zou je ook moeten weten dat dit supercomplex kan zijn als je het zelf moet doen. Puur afhankelijk van wat je aan het maken bent, heb je heel erg te maken met tijd, tijdzones, schrikkelsecondes, historische gegevens.

Zo zijn er landen die ergens een dag hebben overgeslagen, zijn er minuten met 61 seconden geweest, zijn per periodes waar we van kalender zijn gewisseld en 3 weken hebben overgeslagen (In sommige landen), gebruiken mensen in hetzelfde gebied twee verschillende tijdzones, zijn er tijdzones die 15 minuten afwijken. Het gebeurd soms meermalen per jaar dat er landen hun zomer/wintertijd cyclus veranderen, enzovoorts, enzovoorts, enzovoorts.

Het mooiste 'tijdprobleem' wat ik als voorbeeld ken is 'Het milleniumprobleem' dat door sommige mensen als 'overdreven' en 'er was niks aan de hand' werd afgewimpeld. Er was uiteraard niets aan de hand (op wat kleine dingetjes na) omdat er heel veel mensen heel hard aan gewerkt hadden.
Voor degenen die het niet kennen (de jongeren ): De basis van het probleem was dat vroeger opslag heel duur was. Om die reden werden 'tijd' in 2 cijfers voor het jaartal gezet. Dus dus 1983 werd weggeschreven als 83, 1999 werd weggeschreven als 99. Scheelt 2 bytes per transactie. Toen werd het 2000 (00).

Let op wat het beveiligingssysteem van de stroomcentrale denkt:
Hey, ik heb -99 (minus 99 dus) jaar geen onderhoud gehad. Dat is geen 'normale' situatie. Dus onveilig. Dus ik ga uit. (Deze conclusies hadden vrijwel alle iets oudere stroomcentrales in Europa. Want er was een 'onlogische' status in een veiligheidssysteem.) De oplossing was heel simpel. Tegen de software zeggen "Is het getal groter dan 70, dan is het 1900 + de waarde. Is het getal kleiner dan 70, dan is het 2000 + de waarde". Heel simpel. Maar het moest wel geprogrammeerd worden.
Zo waren er nog veel meer zaken. Financiele transacties die ineens terug in de tijd gingen. Certificaten die ineens pas over 95 jaar actief werden, enzovoorts, enzovoorts, enzovoorts.

Tijd is een gedoe. Voor de meeste zaken is het voldoende om gewoon de lokale systeemtijd (of timestamp) te gebruiken en klaar. Een computer weet tenslotte niks van "3 januari 2012". Dat is een mensending. Maar voor heel veel zaken kan het wel degelijk een gedoe zijn.

[cricque]

Yups het is een zootje soms en zeker niet "gemakkelijk" zeker niet als je je daarin volledig moet verdiepen. Ik ben beginnen te werken in 1999 (ben zelf van 79). Maar vandaag de dag kijk ik toch nog altijd naar storage hoor. Als ik een tinyint kan gebruiken of een smallint dan zal het ook dat type zijn. Een string hoeft geen 200 karakters te zijn, als het maximaal 80 kan zijn bijvoorbeeld. Enja dit is in de meeste systemen helemaal niet meer zo van belang, omdat dit ook wel variabel is. Onlangs nog eens een programma onder handen moeten nemen van een bedrijf ... Die bijbehorende db was om te huilen. De code zelf, was ook verre van wat het zou moeten zijn. Wel "top dollar" aangerekend door de maker ... Er was niet veel meer te redden, was echt gewoon ronduit slechte opzet. Veel copy & paste en library hier en daar. Ik ben zeker niet tegen het gebruik van libraries, maar alleen indien nodig. En voor datums en tijd wel daar moet je zeker het wiel niet voor opnieuw uitvinden

[lenwar]

Dit soort incidenten (met ‘computertijd’) komen nog altijd vaker voor dan dat we denken. Het kan ook supercomplex/gevoelig zijn als je er afhankelijkheden van hebt.

Ik moet altijd denken aan dit filmpje. Op een bepaald moment een beetje hysterisch en waarschijnlijk geacteerd, maar hij legt het wel duidelijk uit, wat de problemen kunnen ontstaan.

[Pep7777]

Tijd is en blijft een lastig dingetje, zoveel rare uitzonderingen, schrikkelseconden, tijdzones en zomer/wintertijd. Voor do C++ ontwikkelaars onder ons, als je iets met tijd wil doen gebruik de <chrono> (standaard) library en ga niet zelf lopen rommelen. En zoiets geld ook vast voor andere talen, ga nooit zelf direct met dagen/uren/minuten aan de slag ook al lijkt dat op het eerste gezicht het makkelijkste. Krijg je echt later spijt van.

[lenwar]

Precies dit inderdaad. Eigenlijk de verwoording van m’n gelinkte filmpje. Tijd is een heel lastig ding en kan verregaande gevolgen hebben.
Het blijkt ook serieus lastig. Zelfs grote professionele organisaties als E.A., ziekenhuizen, autofabrikanten, Sophos, betalingsproviders, enz. Zijn dit jaar getroffen. Daar werken echt wel capabele mensen en ook zij hebben zich er blijkbaar verstikt.

Maar denk ook aan precisie van tijd.
Financiële transacties met beurzen moeten met nanoseconden precisie worden uitgevoerd. Dan is een standaard NTP-dienst en computerklok niet meer toereikend.

Of denk aan transacties tussen applicatieservers. Dat luistert onderling supernauw (hoeft niet per ze de echte tijd te zijn, als ze maar dezelfde tijd hebben).

[P_Tingen]

Tot een aantal versies geleden ging de database server die wij gebruiken (OpenEdge) nog down als je de tijd op de server aanpaste van zomer- naar wintertijd. De database crashte dan met een melding in de log á la "The clock has gone backwards, database halted". Dat was omdat die tijd gebruikt werd voor het vastleggen van transacties. Er waren in die tijd tools om de systeemklok een uur op halve snelheid te laten draaien om het tegen te gaan. Tegenwoordig is dat gelukkig iets beter geregeld....

[Zoop]

Kwestie van timestamps gebruiken in plaats van geformateerde dates om mee te rekenen. Dan maken schrikkeljaren of zomertijd helemaal niets uit. Het is dan letterlijk een set nummertjes met elkaar vergelijken, simpeler kan haast niet. Je gaat niet lopen "tijdreizen" met zomertijd, in ieder geval.

Dat er zoveel bedrijven daar toch mee de mist in gaan is echt wel ongelooflijk.

[rubenvb]

niet <chrono> maar <date>. <chrono> is enkel (tick) clocks en durations. <date> doet het hele datum en tijd en kalender verhaal.

[Pep7777]

<date> is geen standard library (ik neem aan dat je Howard Hinnant's library bedoelt : https://howardhinnant.github.io/date/date.html). <chrono> heeft daar sinds C++20 ook weer meer van overgenomen : https://en.cppreference.com/w/cpp/chrono. Maar <date> is zeker geen verkeerde optie. Belangrijkste gegeven is je moet tijd bijhouden dmv een strict monotoon stijgende klok, alles wat je aan jaren, maanden, dagen, uren en minuten (en tijdzones) laat zien zijn slechts representaties van die onderliggende "waarheid"

[juke1349]

Mooi filmpje!

Uit mijn eigen bookmarks:
Infinite Undo: Falsehoods programmers believe about time (en deel 2)

En mijn lievelings-post-mortem (zowel qua oorzaak, als qua openheid, blameless-factor en lessons learned)
Summary of Windows Azure Service Disruption on Feb 29th, 2012 (wereldwijde storing, omdat interne security certificaten een geldigheid tot, ongeldige, 29 februari 2013 kregen, dus de hele cloud in safety shutdown ging)

[sspiff]

Een ander slachtoffer van 29/2: https://arstechnica.com/g...ealand-for-over-10-hours/

[DoctorBazinga]

Ik heb juist daarom een jaarabonnement afgesloten (en volledig vooruitbetaald) en er wordt aangegeven dat hij stopt op 29.02.2025.
Dus hopelijk nooit.

[Reactie gewijzigd door DoctorBazinga op 24 juli 2024 10:11]

[Byte]

Deze man speelt 4D chess
Lijkt mij fantastisch als dit werkt, ze zullen vast wel een fix uitbrengen als dit het geval zou zijn!

[DoctorBazinga]

Nou ik heb zo ook 8 jaar gratis een usenetabbonement gehad.
Todat het betreffende pakket/abbonement niet meer zo werd aangeboden.

Dus het valt altijd te proberen. 🤷🏻

[Reactie gewijzigd door DoctorBazinga op 24 juli 2024 10:11]

[Sn1peSh0t]

Graag volgend jaar even een update

[GenomDalar1983]

Waarschijnlijk stopt ie dus gewoon op/na 01.03.2025

[DoctorBazinga]

Weet jij het 1000% zeker ? 🤷🏻

“Niet geschoten is altijd mis.”

“We zullen het zien (zei de blinde) “

[Reactie gewijzigd door DoctorBazinga op 24 juli 2024 10:11]

[PdeBie]

He kak. Kans gemist. Over 4 jaar weer proberen.

[LinuX-TUX]

Goh, je zou toch een schijfje hebben als recht kopende en het kunnen afspelen zoals vroeger.

Hoe langer ik erbij stilsta en hoe langer ik ook consoles de fysieke media de wereld uit zie drijven, hoe langer ik me er vanaf houd. Plug en play, fysiek, mijn cardridge/CD en nu GO. WTF tijd issue, laatste reden waaraan ik had kunnen denken om iets fysiek te willen hebben.

[Shadow771]

Misschien moet er morgen eens een summery komen van alles in de wereld wat technisch hinder kreeg van 29 februari.

[Noxious]

Diverse 'fleets' van autonome auto's staan stil omdat ze twee specifieke generaties van Lidar's gebruiken:
https://pandaily.com/hesa...esses-lidar-products-bug/

In Nieuw-Zeeland kun je niet tanken bij self-service tankstations:
https://arstechnica.com/g...ealand-for-over-10-hours/

Edit, hier nog een mooie lijst:
https://codeofmatt.com/list-of-2024-leap-day-bugs/

[Reactie gewijzigd door Noxious op 24 juli 2024 10:11]

[Zexion]

Hier in Zweden lag een van de grotere supermarkt ketens soort van plat. De bug werd vrij snel verholpen, maar klanten konden in de vroege ochtend niet betalen
https://www.aftonbladet.s...aller-med-skora-it-system

[RvdDungen]

Dank u Tweakers, ik had het nodig even goed te lachen.

[DoctorBazinga]

Ik ook.

Wat een klunzen. 🤦🏻

[Zexion]

Hier in Zweden lag vandaag een van de grootste supermarktketens soort van plat.
Betalingen konden niet verwerkt worden vanwege de schrikkeldag.
Sh*t happens

[thijs1993]

Iedereen die deze game gespeeld heeft is hier natuurlijk niet verbaasd over. Dit is bijna net zo onbegrijpelijk als een rally game die stutters heeft

[Zexion]

Het feit dat de game er minder goed uit ziet dan DiRT Rally 2.0 en al sinds release niet soepel loopt op high-end systemen is echt dramatisch. Sinds de 1.5 patch is performance echt wel een stuk beter geworden, maar als ik mijn koplampen aan zet verlies ik 20% fps.
Het is echt droevig.

[AbuFalafel]

Het is zo triest dat WRC de laatste jaren terecht komt bij waardeloze ontwikkelaars. Nacon had er een bende van gemaakt, iedereen was blij dat het vanaf 2023 ontwikkeld zou worden door Codemasters, totdat het bleek dat EA Codemasters had gekocht

[AW_Bos]

Hoe is het mogelijk dat een spel afhankelijk is van een functie om de datum en tijd te berekenen, die dus buggy werkt? Als het operating system er geen problemen mee heeft, waarom zou je die niet vertrouwen?

[Bose321]

Get is ook lastig voor een kleine indie developer om zulke triviale problemen te voorkomen.