Vinnaren i pepparkakshustävlingen!
2024-03-01, 13:15
  #97
Medlem
xitunos avatar
Citat:
Ursprungligen postat av Gravallvarlig
Den riktiga buggen kommer 2038 när Unix-time når en stack overflow. Då ni!

Nej, ingen stack overflow, utan en integer overflow. Väldigt stor skillnad.

Problemet beror på att endast 32 bitar används för att hålla reda på antalet sekunder som passerat sedan 1 januari 1970. Med 32 bitar går det att hålla reda på totalt 4294967296 sekunder, 2147483648 före den 1 januari 1970 och 2147483647 efter. Eller från fredagen den 13 januari 1901 20:45:52 till tisdagen den 19 januari 2038 03:14:07.

De flesta system som aktivt används idag har sedan länge gått över till 64 bitar, som klarar av att hålla reda på fler sekunder än vad som totalt inträffat i universum flera gånger om.

Ett problem som kommer att uppkomma är dock at många binära format (både filformat och överföringsprotokoll) innehåller tidsstämplar som bara är 32 bitar. De går inte enkelt att ändra på. Det finns mängder med databaser där tiden sparats som 32 bitar. De måste uppdateras.
Citera
2024-03-01, 13:46
  #98
Medlem
xitunos avatar
Citat:
Ursprungligen postat av kaReri182
Personligen var jag en av få som agerade aktivt för att upplysa makthavare och allmänhet om att riskerna var oerhört överdrivna.

Det förekom en hel del överdrifter, men problemet var verkligt. Det var många system som behövde uppdateras. Databaser som bara sparade årtalet som två siffor, överföringsformat som bara använde två siffror. System som använde 99 i årtalet för att indikera ogiltigt/övrigt.

Citat:
Ursprungligen postat av kaReri182
Som exempel kan jag nämna att jag behövde ändra en enda kodrad (hantering av en realtidsklocka från en extern leverantör) i det mest avancerade processtyrsystem som vid den tiden hade levererats i Sverige.

En del fixar var väldigt lätta att åtgärda, som den du beskriver ovan. Även om de var lätta att fixa hade det inte varit så kul om alla fel inträffade samtidigt. Och vilka konsekvenser hade det fått för de processer som styrdes av systemet? Förlorad produktion? Användes det i en industri där förlorad kontroll över processen kunde leda till livsfara?

Det behövdes en ordentlig genomgång av alla system för att identifiera vilka som behövde uppdateras / bytas ut. Redan under 1980-talet började det pratas om det och en del tog till sig informationen. Ett exempel är när Skatteverket tog över folkbokföringen 1991 så valde man att spara årtalet i personnumren som 4 siffror.
Citera
2024-03-01, 14:03
  #99
Medlem
Säkert en gammal trött IT-avdelning som tycker att Microsoft är kung.
Citera
2024-03-01, 14:32
  #100
Medlem
Citat:
Ursprungligen postat av xituno

En del fixar var väldigt lätta att åtgärda, som den du beskriver ovan. Även om de var lätta att fixa hade det inte varit så kul om alla fel inträffade samtidigt. Och vilka konsekvenser hade det fått för de processer som styrdes av systemet? Förlorad produktion? Användes det i en industri där förlorad kontroll över processen kunde leda till livsfara?

Det behövdes en ordentlig genomgång av alla system för att identifiera vilka som behövde uppdateras / bytas ut. Redan under 1980-talet började det pratas om det och en del tog till sig informationen. Ett exempel är när Skatteverket tog över folkbokföringen 1991 så valde man att spara årtalet i personnumren som 4 siffror.

Ytterst få, om något, system behövde egentligen bytas ut pga av risker med millenieskiftet. Visst behövde systemen "ses över" , men det lades ner 100-falt mer tid än nödvändigt. De flesta "fel" som upptäcktes var av kosmetisk natur (tex presentera årtal som 4 siffror i stf 2) och behövde i många fall inte åtgärdas för att systemen skulle fungera.
Citera
2024-03-01, 17:15
  #101
Medlem
Citat:
Ursprungligen postat av zeSecret
Ni som inte är programmerare förstår inte att jobba med tid/datum är väldigt jobbigt och för det mesta krångligt och finns en del cornercases som man kan missa.

Tex idag så satt jag med en test suite som inte gick igenom så en hel pipeline gick inte igenom för man backade ett år och tog inte hänsyn till skottår. Koden var skriven 2020 så problemet identifierades inte förens idag.

/systemutvecklare över 15 år
Just skottåret är oerhört enkelt att programmera! Det måste vara årets sämsta programmerare som missar en sådan sak. Jag skall medge att jag själv med flit programmerat in ett skottårsfel - min kod, som jag skrev i slutet på 1900-talet, tar inte hänsyn till att år 2100 inte är skottår. Jag räknar med att min kod inte kommer att vara aktuell då.
/systemutvecklare i knappt 40 år, hade mindre än 10 års erfarenhet när jag hanterade skottåret enl ovan.
Citera
2024-03-01, 18:11
  #102
Medlem
Var det lika för 4 år sen? Nytt datasystem? Inkompetenta människor som jobbar på ICA-Banken?
Citera
2024-03-01, 18:16
  #103
Medlem
En väldigt nitisk bank mot kunder. Själva kan ICA-banken inte sköta det enkla och självklara.
Citera
2024-03-01, 19:09
  #104
Medlem
Citat:
Ursprungligen postat av Mentat57
Just skottåret är oerhört enkelt att programmera! Det måste vara årets sämsta programmerare som missar en sådan sak. Jag skall medge att jag själv med flit programmerat in ett skottårsfel - min kod, som jag skrev i slutet på 1900-talet, tar inte hänsyn till att år 2100 inte är skottår. Jag räknar med att min kod inte kommer att vara aktuell då.
/systemutvecklare i knappt 40 år, hade mindre än 10 års erfarenhet när jag hanterade skottåret enl ovan.

Skottår är enkelt att identifiera, ja (se tidigare post) men datumtid är ändå enkelt att skriva buggar på.
Citera
2024-03-01, 22:21
  #105
Medlem
Prövade lite gemini ai igår natten till idag. Även den där ai verkade helt körd på datumet till min förvåning. Den påstod 1 mars 2024 var en onsdag först, sedan påstod den det var en torsdag.

Men det fick mig fundera lite, jag frågade chatgpt angående unix/epoch tid, om de tar med leap year - och enligt den så gör den det.
Bör det ej då gå att använda epoch tid i systemet och därav simpelt konvertera tider emellan? Det körde jag på när jag en gång körde tasker till google spreadsheet, supersimpel lösning med räkna tid mellan två tidpunkter samt få dessutom datum eller vad man vill.
Hade säkert undvikit buggar med datum
Citera
2024-03-01, 23:31
  #106
Medlem
henrikos avatar
Citat:
Ursprungligen postat av Ganonito
Naturligtvis ohållbart. Hur ska de ens veta vad varan ska kosta om inte kassasystemet funkar?

De skulle kunna ha en så kallad skrivare på kontoret, där de skriver ut på papper en gång i kvartalet. Typ en sida per avdelning i affären, och sedan alfabetiskt. Dessutom en lång jävla lista sorterad efter produktnumret för det de inte hittar.

Visst det kommer då inte vara exakt samma priser som de hade dagen innan, men bättre det än att slänga allt tänker jag.
Citera
2024-03-01, 23:31
  #107
Medlem
henrikos avatar
Citat:
Ursprungligen postat av Jonas1968
Ja skottår är ju inte precis någon nyhet utan har funnits ända sedan långt före vår tideräknings början.

Nej, skottåren infördes efter vi började räkna tid.
Citera
2024-03-01, 23:32
  #108
Medlem
henrikos avatar
Citat:
Ursprungligen postat av zeSecret
Ni som inte är programmerare förstår inte att jobba med tid/datum är väldigt jobbigt och för det mesta krångligt och finns en del cornercases som man kan missa.

Tex idag så satt jag med en test suite som inte gick igenom så en hel pipeline gick inte igenom för man backade ett år och tog inte hänsyn till skottår. Koden var skriven 2020 så problemet identifierades inte förens idag.

/systemutvecklare över 15 år

Man kan tycka att detta borde ha fångats upp av tester. Fast det kanske var en jätteudda bugg som dök upp vissa skottår bara?
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback