Tidsformatering och lagringsbuggar
Inom datavetenskap är tidsformaterings- och lagringsbuggar en klass av programvarubuggar som orsakar fel vid beräkning eller visning av tid och datum . Dessa är oftast manifestationer av aritmetiskt spill , men kan också vara resultatet av andra problem. Den mest kända konsekvensen av buggar av denna typ är Y2K-problemet , men många andra milstolpsdatum eller tidpunkter finns som har orsakat eller kommer att orsaka problem beroende på olika programmeringsbrister.
År 1975
Den 4 januari 1975 flödade 12-bitarsfältet som hade använts för datum i operativsystemen DECsystem-10 över. Det fanns många problem och krascher relaterade till denna bugg medan ett alternativt format utvecklades.
År 1978
Operativsystemet Digital Equipment Corporation OS/8 för PDP-8- datorn använde endast tre bitar för året, vilket representerar åren 1970 till 1977.
Detta upptäcktes när det senare operativsystemet COS-310 utvecklades, och datum registrerades på olika sätt.
År 1993
Flera Sierra Entertainment- spel som släpptes för Classic Mac OS började frysa när de kördes den 18 september 1993. Ett problem i Mac-versionen av Sierras Creative Interpreter (Mac SCI) skulle få spelet att "låsa sig" när man försökte hantera en fördröjning på grund av ett problem med översvämning. Mac SCI skulle försöka använda datumet för att bestämma hur länge en fördröjning ska pågå genom att få den aktuella tiden i sekunder sedan 1 januari 1904, Macintosh- epoken , och dividera med 12 timmar. Uppdelningen bearbetades av Motorola 68000 och skulle inte inträffa om ett överflöde upptäcktes på grund av uppdelningen, men Mac SCI skulle fortsätta oavsett som om uppdelningen hade inträffat, vilket så småningom resulterade i att en fördröjning på en sekund behandlades som en fördröjning i 18 timmar och så vidare. Sierra släppte en patch som heter MCDATE som löste problemet i nästan 14 år .
År 1997
Domän /OS -klockan, som är baserad på antalet 4 mikrosekundersenheter som har inträffat sedan 1 januari 1980, rullade förbi 47 bitar den 2 november 1997, vilket gjorde oparpade system oanvändbara.
År 1999
Under de sista månaderna före år 2000 inträffade två andra datumrelaterade milstolpar som fick mindre publicitet än det då överhängande Y2K-problemet.
Första GPS-rullningen
GPS-datum uttrycks som ett veckonummer och ett veckodagnummer, med veckonummer som ett tiobitarsvärde . Detta innebär att var 1 024:e vecka (cirka 19,6 år) efter söndagen den 6 januari 1980 (GPS- epoken ) återställs datumet till det datumet; detta hände för första gången kl. 23:59:47 den 21 augusti 1999, andra gången kl. 23:59:42 UTC den 6 april 2019 och kommer att hända igen den 20 november 2038. För att ta itu med denna oro moderniserade GPS-navigeringsmeddelanden använd ett 13-bitarsfält, som bara upprepas var 8 192:e vecka (157 år), och kommer inte att återgå till noll förrän år 2137.
9/9/99
I många program eller datauppsättningar användes "9/9/99" som ett oseriöst värde för att ange antingen ett olöst datum eller som en terminator för att indikera att ingen ytterligare data fanns i uppsättningen. Detta väckte problem vid ankomsten av det faktiska datumet som detta representerar, den 9 september 1999.
År 2000
Tvåsiffriga årsrepresentationer
Uppföljningsproblem orsakade av vissa tillfälliga korrigeringar av Y2K-problemet kommer att dyka upp vid olika tillfällen under 2000-talet. Vissa program gjordes Y2K-kompatibla genom att fortsätta använda tvåsiffriga år, men välja ett godtyckligt år före vilket dessa år tolkas som 20 xx , och därefter tolkas som 19 xx .
Till exempel kan ett program ha ändrats så att det behandlar tvåsiffriga årsvärden 00–68 som hänvisningar till 2000 till 2068, och värdena 69–99 som hänvisar till 1969 till 1999. Ett sådant program kommer inte att kunna hantera korrekt med år efter 2068.
För applikationer som krävs för att beräkna födelseåret (eller ett annat tidigare år) har en sådan algoritm länge använts för att övervinna år 1900-problemet, men den har misslyckats med att känna igen personer över 100 år .
År 2001
System som använde en sträng på nio siffror för att registrera tiden som sekunder sedan Unix-epoken hade problem med att rapportera tider längre än en miljarddels sekund efter epoken den 9 september 2001 kl. 01:46:40 ("billenium"). Problemen var inte utbredda.
År 2007
Sierra Entertainment-spel för Classic Mac OS som patchades med MCDATE-programmet eller släpptes efteråt med patchen inbyggd skulle börja frysa den 28 maj 2007. Precis som med #Year 1993 -programmet berodde detta på ett problem i Mac SCI när du försöker använda datumet för att avgöra hur länge en försening ska pågå. Program med MCDATE-patchen fryser eftersom Mac SCI tar det nuvarande antalet sekunder sedan Macintosh-epoken den 1 januari 1904, subtraherar 432 000 000 sekunder från det och dividerar sedan med 12 timmar genom Motorola 68000, för att sedan avgöra hur långa förseningar ska vara . Den 28 maj 2007 delar sig inte Motorola 68000 igen på grund av översvämningsskydd, vilket Mac SCI ignorerar.
År 2010
Vissa system hade problem när året väl gick över till 2010. Detta kallades av vissa i media som "Y2K+10" eller "Y2.01k"-problemet.
Den främsta källan till problem var förvirring mellan hexadecimal nummerkodning och BCD- kodning av nummer. Siffrorna 0 till 9 är kodade i både hexadecimal och BCD som 00 16 till 09 16 . Men decimaltalet 10 är hexadecimalt kodat som 0A 16 och i BCD som 10 16 . Således representerar en BCD 10 16 tolkad som en hexadecimal kodning felaktigt decimaltalet 16.
Till exempel använder SMS- protokollet BCD-kodning för datum, så vissa mobiltelefonprogram rapporterade felaktigt datum för meddelanden som 2016 istället för 2010. Windows Mobile var den första programvaran som rapporterades ha påverkats av detta fel; i vissa fall ändrade WM6 datumet för alla inkommande SMS-meddelanden som skickades efter den 1 januari 2010, från år 2010 till 2016.
Andra system som påverkas inkluderar EFTPOS- terminaler och PlayStation 3 (förutom Slim-modellen).
Sonys PlayStation 3 behandlade felaktigt 2010 som ett skottår, så den obefintliga 29 februari 2010 visades den 1 mars 2010 och orsakade ett programfel .
Det viktigaste sådana felet inträffade i Tyskland, där uppemot 20 miljoner bankkort blev oanvändbara, och med Citibank Belgium, vars digipass-kundidentifieringschip slutade fungera.
År 2011
Taiwan använder officiellt Minguo-kalendern , som anser att det gregorianska året 1912 är dess år 1. Det gregorianska året 2011 är alltså ROC-året 100, dess första tresiffriga år.
År 2013
Rymdsonden Deep Impact förlorade kommunikationen med jorden den 11 augusti 2013 på grund av ett tidstaggningsproblem; datumet lagrades som ett osignerat 32-bitars heltal som räknar antalet tionde sekunder sedan 1 januari 2000.
År 2019
Andra GPS-vältning
Under 2019 inträffade den andra övergången av GPS-veckans nummer .
Japansk kalenderövergång
Den 30 april 2019 abdikerade kejsar Akihito av Japan till förmån för sin son Naruhito . Eftersom år i Japan traditionellt hänvisas till med eranamn som motsvarar varje kejsares regeringstid, resulterade detta i ett nytt eranamn, Reiwa ( 令和 ) , efter Naruhitos trontillträde följande dag. Eftersom den tidigare kejsaren, Hirohito , dog den 7 januari 1989, och Akihitos regeringstid mestadels motsvarade ökningen av användningen av datorer, hade de flesta mjukvaror inte testats för att säkerställa korrekt beteende vid en eraförändring, medan testningen komplicerades ytterligare av det faktum att namnet på den nya eran avslöjades inte förrän den 1 april 2019. Därför förväntades fel från programvara som inte förutsåg en ny era.
År 2020
TV-spelen WWE 2K20 och Star Wars Jedi: Fallen Order kraschade båda den 1 januari 2020, när året rullade över. Felen kunde bara kringgås genom att återställa året till 2019 tills en patch släpptes. Dessutom Crystal Reports 8.5 misslyckas med att generera specifika rapporter från och med 2020.
Parkeon parkeringsmätare i New York City och andra platser kunde inte acceptera kreditkort som betalningsmetod från och med 2020. En lösning implementerades, men krävde att varje mätare uppdaterades individuellt. I New York beräknades mätarna vara fixade förrän den 9 januari.
I Polen slutade 5 000 kassaapparater att skriva ut datumet ordentligt.
Suunto sport smarta klockor visade ett fel vid beräkning av veckodagar som presenterades med ett +2-steg (t.ex. FRI snarare än WED, LÖR snarare än THU). För Suunto Spartan-modellklockor fixades buggen med firmwareversion 2.8.32.
Klassiskt Mac OS
Kontrollpanelen i klassiska Mac OS versioner 6, 7 och 8 tillåter endast att datumet ställs in så högt som 31 december 2019, även om systemet kan fortsätta att flytta fram tiden efter detta datum.
År 2021
Samsung-användare rapporterade att telefoner som körs med den senaste One UI 3.0-uppdateringen eller Android 11 förlorade åtkomsten till batteri- och laddningsstatistiken från och med 2021. Berörda enheter skulle inte rapportera användningsstatistik, vilket lämnade dessa avsnitt tomma.
År 2022
Datum som lagras i formatet yymmddHHMM konverterade till ett signerat 32-bitars heltal svämmade över den 1 januari 2022, som 2 31 =2147483648. Särskilt påverkad var uppdateringsnumren för skanningskomponenten för skadlig programvara för Microsoft Exchange , som verkar användas för en matematisk kontroll för att fastställa den senaste uppdateringen.
Honda- och Acura-bilar tillverkade mellan 2004 och 2012 som innehöll GPS-navigeringssystem visade felaktigt årtalet som 2002. Detta problem berodde på ett översvämning under GPS-epoken. Honda bekräftade att problemet skulle lösa sig den 17 augusti 2022. [ behöver uppdateras ]
År 2025
I Japan räknar vissa äldre datorsystem som använder den japanska kalendern som inte har uppdaterats fortfarande år enligt Shōwa-eran . År 2025 motsvarar i dessa system Shōwa 100, vilket kan orsaka problem om programvaran antar två siffror för året.
År 2028
Vissa system lagrar sitt år som en enkelbyte-offset från 1900, vilket ger ett intervall på 255 (8 bitar) och gör att datum upp till 2155 kan representeras säkert. Men inte alla system använder en osignerad byte: vissa har felaktigt kodats med en signerad byte som endast tillåter ett intervall på 127 år, vilket innebär att datumfältet i programvaran kommer att vara felaktigt efter 2027 och kan orsaka oförutsägbart beteende. Flera delar av mjukvara för optiska skivor som använder ISO 9660 -formatet påverkas av detta.
Under slutet av 1970-talet, på Data General Nova och Eclipse-system, skapade World Computer Corporation (som gör kreditföreningsapplikationer) ett datumformat med ett 16-bitars datumfält för 128 år (7 bitar – notera 1900+128=2028), 12 månader (4 bitar) och 31 dagar (5 bitar). Detta gjorde det möjligt för datum att vara direkt jämförbara med osignerade funktioner. Vissa system, inklusive HP 3000 , använder fortfarande detta format, även om en patch har utvecklats av externa konsulter.
År 2032
Palm OS använder både signerade heltal med 1970- epoken , såväl som osignerade heltal med 1904-epoken, för olika systemfunktioner, såsom för systemklocka och fildatum (se PDB-format ). Även om detta borde resultera i att Palm OS är mottagligt för 2038-problemet använder Palm OS också ett 7-bitarsfält för att lagra årsvärdet, med en annan epok som räknas från 1904, vilket resulterar i ett maximalt år 2031 (1904+127).
År 2036
Network Time Protocol har ett spillproblem relaterat till år 2038-problemet , som visar sig klockan 06:28:16 UTC den 7 februari 2036, snarare än 2038. De 64-bitars tidsstämplar som används av NTP består av en 32-bitars del för sekunder och en 32-bitars del för bråkdelssekunder, vilket ger NTP en tidsskala som rullar över var 2:e 32:e sekund (136 år) och en teoretisk upplösning på 2 -32 sekunder (233 pikosekunder). NTP använder en epok från 1 januari 1900. Den första övergången inträffar 2036, före UNIX-år 2038-problemet.
År 2038
Unix-tidsövergång
Den ursprungliga implementeringen av Unix -operativsystemet lagrade systemtiden som ett 32-bitars signerat heltal som representerar antalet sekunder efter Unix-epoken : midnatt UTC 00:00:00 torsdagen den 1 januari 1970. Detta värde kommer att rulla över efter 03: 14:07 UTC tisdagen den 19 januari 2038. Detta problem har åtgärdats i de flesta moderna Unix- och Unix-liknande operativsystem genom att lagra systemtid som ett 64-bitars signerat heltal, även om enskilda applikationer, protokoll och filformat måste ändras också.
Windows C runtime-bibliotek
Liksom Unix time rollover-frågan har 32-bitarsversionen av gmtime i C runtime-biblioteken på Windows ett liknande problem.
Det här problemet har redan visat sig i Oracles Access Manager version 10.1.4.3 för Windows. Identity Console-komponenten ställer in en cookie som innehåller UI- inställningar med ett utgångsdatum på 500 000 000 sekunder i framtiden (drygt 15 år, 308 dagar, 53 minuter och 20 sekunder). Detta är efter 19 januari 2038 och därför ger det ett undantag för vissa sökaktiviteter efter den 17 mars 2022, kl. 02:20:48 eftersom gmtime_r()-anropet inte kan konvertera det angivna numret till ett datum för att skriva till cookien. Trots programvarans ålder (18 juni 2009) utfärdade Oracle en patchnummer 33983548 den 6 april 2022.
Tredje gps-rollover
Den tredje övergången av GPS-veckans nummer kommer att ske den 20 november 2038, klockan 23:59:37 UTC.
År 2040
Tidiga Apple Macintosh -datorer lagrar tid i sina realtidsklockor (RTC) och HFS -filsystem som ett osignerat 32-bitars antal sekunder sedan 00:00:00 den 1 januari 1904. Efter 06:28:15 den 6 februari 2040, ( dvs 2 32 −1 sekunder från epoken), kommer detta att ta sig runt 1904: utöver detta påverkas också HFS+, standardformatet för alla Apples senaste Macintosh-datorer. Det ersättande Apple-filsystemet löser problemet.
ProDOS för Apple II -datorerna stöder endast tvåsiffriga årtal. För att undvika Y2K-problem utfärdade Apple en teknisk notering som anger att årstalet skulle representera 1940–2039. Programvara för plattformen kan felaktigt visa datum som börjar 2040, även om en tredje parts ansträngning pågår för att uppdatera ProDOS och applikationsprogramvara för att stödja år upp till 4095.
År 2042
Den 18 september 2042 kommer Time of Day Clock (TODC) på S/370 IBM stordatorn och dess efterföljare, inklusive den nuvarande zSeries, att rulla över.
Äldre TODC:er implementerades som en 64-bitars räkning på 2-12 mikrosekunder (0,244 ns) enheter, och standardbasen var 1 januari 1900, UT . I juli 1999 tillkännagavs den utökade TODC-klockan, som utökade klockan till höger (det vill säga de utökade bitarna är mindre signifikanta än de ursprungliga bitarna). Den faktiska upplösningen beror på modellen, men formatet är konsekvent och kommer därför att rulla över efter 2 52 mikrosekunder.
TODC-värdet är tillgängligt för användarlägesprogram och används ofta för timing och för att generera unika ID:n för händelser.
Medan IBM har definierat och implementerat ett längre (128-bitars) hårdvaruformat på nya datorer, vilket förlänger timern i båda ändarna med minst 8 ytterligare bitar, fortsätter många program att förlita sig på 64-bitarsformatet som förblir en tillgänglig delmängd av den längre timern.
År 2048
ATSC - systemet kommer att ha ett problem som liknar DVB-problemet som beskrivs ovan efter 2048 på grund av dess användning av signerade 32-bitars GPS-sekunder som börjar från 6 januari 1980.
Kapacitetsplaneringslogiken i affärssystemet SAP S/4HANA stöder endast slutdatum fram till 19 januari 2048 (24 855 dagar från 1 januari 1980). Det gäller t.ex. produktion, underhåll och inspektionsplanering.
År 2069
Enligt Single UNIX Specification för att analysera tvåsiffriga år med strptime( ), ska "värden i intervallet [69,99] hänvisa till åren 1969 till och med 1999 och värden i intervallet [00,68] ska hänvisa till år 2000 till 2068 inklusive", vilket betyder att när det analyseras med strptime() , skulle det tvåsiffriga året "69" tolkas som 1969 snarare än 2069.
År 2079
Dag 32 768 och 65 536
Program som lagrar datum som antalet dagar sedan ett godtyckligt datum (eller epok ) är sårbara för roll-over eller omslutande effekter om värdena inte är tillräckligt breda för att tillåta datumvärdena att spänna över ett tillräckligt stort tidsintervall som förväntas för Ansökan. Signerade 16-bitars binära värden rullar över efter 32 768 (2 15 ) dagar från epokdatumet, vilket ger negativa värden. Vissa stordatorsystem upplevde programvarufel eftersom de hade kodat datum som antalet dagar sedan 1 januari 1900, vilket gav oväntade negativa dagtal på övergångsdatumet den 18 september 1989. På samma sätt flödar osignerade 16-bitars binära dagar över efter 65 536 (2 16 ) dagar, som är trunkerade till nollvärden. För programvara som använder en epok från 1 januari 1900 kommer detta att inträffa den 6 juni 2079.
År 2080
Vissa (om inte alla) Nokia-telefoner som kör Series 40 (som Nokia X2-00 ) stöder endast datum fram till 31 december 2079, och kommer därför inte att kunna visa datum efter detta. En lösning är att använda år 1996, 2024 eller 2052 i stället för 2080 (som kompatibla skottår) för att visa rätt veckodag, datum och månad på huvudskärmen.
System som lagrar året som ett tvåsiffrigt värde 00..99 endast internt, som många RTC:er, kan rulla över från 31 december 2079 till IBM PC- och DOS- epoken 1980-01-01 .
År 2100
DOS och Windows fildatum API och konverteringsfunktioner (som INT 21h /AH=2Ah) stöder endast officiellt datum fram till 31 december 2099 (även om det underliggande FAT-filsystemet teoretiskt skulle stödja datum upp till 2107). Därför kan DOS-baserade operativsystem, såväl som applikationer som konverterar andra format till FAT/DOS-formatet, visa oväntat beteende från och med den 1 januari 2100.
Ett annat problem kommer att dyka upp i slutet av den 28 februari 2100, eftersom 2100 inte är ett skottår . Eftersom många vanliga implementeringar av skottårsalgoritmen är ofullständiga eller förenklade, kan de felaktigt anta att 2100 är ett skottår, vilket gör att datumet flyttas över från 28 februari 2100 till 29 februari 2100 istället för 1 mars 2100.
Nintendo DS och GameCube, såväl som Sony PlayStation 4, tillåter endast användare att ställa in datum fram till år 2099. När det gäller Nintendo DS kommer systemet inte att förlänga tiden efter den 31 december 2099, medan GameCube och PS4 kommer fortfarande att rulla över till 2100 och framåt, även om användare av dessa spelkonsoler inte kan mata in datum och tid manuellt så långt ut.
År 2106
Många befintliga filformat, kommunikationsprotokoll och applikationsgränssnitt använder en variant av Unix time_t -datumformat, som lagrar antalet sekunder sedan Unix-epoken (midnatt UTC, 1 januari 1970) som ett osignerat 32-bitars binärt heltal. Detta värde kommer att rullas över den 7 februari 2106 kl. 06:28:15. Det vill säga, vid denna tidpunkt är antalet sekunder sedan 1 januari 1970 FFFF FFFF i hex.
Detta problem med lagringsrepresentation är oberoende av program som internt lagrar och arbetar på systemtider som 64-bitars signerade heltalsvärden.
År 2108
Datumtidsstämplarna lagrade i FAT-filsystem , som ursprungligen introducerades med 86-DOS 0.42 den 25 februari 1981 och överfördes till MS-DOS , PC DOS , DR-DOS etc., kommer att svämma över i slutet av 31 december 2107. Senaste ändringsdatumet stämpel (och med DELWATCH 2.0+ även filraderingsdatumstämpeln , och eftersom DOS 7.0 + valfritt även stämpeln för sista åtkomstdatum och stämpel för skapandedatum ), lagras i katalogposten med året representerat som ett osignerat sjubitarsnummer (0) –127), i förhållande till 1980, och kan därmed inte ange några datum under år 2108 och därefter. API -funktionerna som definierats för att hämta dessa datum stöder officiellt endast datum fram till 31 december 2099.
Detta kommer också att påverka ZIP-arkivfilformatet eftersom det använder tidsstämplar för FAT-filmodifiering internt.
År 2137
GPS-datum uttrycks som ett veckonummer och ett veckodagnummer, där veckonummer initialt använder ett tiobitarsvärde och moderniserade GPS-navigeringsmeddelanden med ett 13-bitarsfält. Tio-bitarssystem skulle rulla över var 1024:e vecka (cirka 19,6 år) efter söndagen den 6 januari 1980 (GPS- epoken ), och 13-bitars system rullade över var 8192:e vecka. Tretton-bitars system kommer att rulla över till noll år 2137.
År 2262
Vissa tidtagningssystem räknar nanosekunder sedan 1970 med ett 64-bitars signerat heltal, som kommer att svämma över den 11 april 2262, 23:47:16. Go -programmeringsspråkets UnixNano API är ett exempel. Andra exempel inkluderar Timestamp-objektet i Python pandas , C++ chrono::system_clock, [ misslyckad verifiering – se diskussion ] och QEMU -timers.
År 2286
System som använder en sträng på 10 tecken för att spela in UNIX-tiden kan ha problem med att rapportera tider utöver den tio miljarder sekunden efter den 20 november 2286, kl. 17:46:40
År 4000, 8000 osv.
På tidsskalor av tusentals år hamnar den gregorianska kalendern efter de astronomiska årstiderna. Detta beror på att jordens rotationshastighet gradvis saktar ner, vilket gör varje dag något längre över tiden (se tidvattenacceleration och skottsekund ) medan året bibehåller en mer enhetlig varaktighet.
På 1800-talet föreslog Sir John Herschel en modifiering av den gregorianska kalendern med 969 skottdagar vart 4000:e år, istället för 970 skottdagar som den gregorianska kalendern skulle infoga under samma period. Detta skulle minska det genomsnittliga året till 365,24225 dagar. Herschels förslag skulle göra år 4000, och multiplar därav, vanligt i stället för språng. Även om denna ändring ofta har föreslagits sedan dess har den aldrig antagits officiellt.
Medan de flesta mjukvaror (inklusive Excel , JavaScript och R ) för närvarande känner igen 4000 och 8000 som skottår (eftersom de är delbara med 400), har SAS antagit "4000-årsregeln". Med den nuvarande mjukvaran kommer alltså datumkonverteringar mellan SAS och annan mjukvara att gå ur synk efter den 28 februari 4000.
År 4501
Microsoft Outlook använder datumet 1 januari 4501 som platshållare för "ingen" eller "tom".
År 10 000
År 10 000 blir det första gregorianska året med fem siffror. Även om många till en början anser att detta år är så långt borta att ett problem av den här typen faktiskt aldrig kommer att uppstå, behöver vissa klasser av beräkningar inom discipliner som astronomi och fysik redan arbeta med år av denna storlek och större. Dessa ansökningar måste också hantera år noll-problemet . Alla framtida år som är makter av 10 har potential för liknande problem.
"RFC 2550 – Y10K and Beyond" diskuterar lösningar för att hantera detta problem. Även om detta är en av "April Fool" RFC:erna, lyfter den viktiga poäng när den är klädd med en generös portion humor.
Exempel
Detta problem kan ses i kalkylbladsprogrammet Microsoft Excel från och med 2023, som lagrar datum som antalet dagar sedan 31 december 1899 (dag 1 är 1 januari 1900) med en fiktiv skottdag år 1900 om man använder standarddatumsystemet 1900. Alternativt, om du använder 1904-datumsystemet, lagras datumet som antalet dagar sedan 1 januari 1904 (dag 1 är 2 januari 1904), och det finns inget skottårsproblem. Maximalt stöddatum för beräkning är 31 december 9999.
År 30.828
Från och med den 14 september 30 828 kommer Windows inte att acceptera datum efter denna dag och vid uppstart kommer det att visa ett felmeddelande angående "ogiltig systemtid" i NTFS. Detta beror på att FILETIME-värdet i Windows, som är ett 64-bitarsvärde som motsvarar antalet 100-nanosekundersintervaller sedan 1 januari 1601, 00:00:00.0000000 UTC, kommer att svämma över sitt maximalt möjliga värde den dagen kl . 02:48 :05.4775808 UTC.
År 32,768 och 65,536
Program som behandlar år som 16-bitarsvärden kan stöta på problem med att hantera antingen år 32 768 eller 65 536, beroende på om värdet behandlas som ett heltal med tecken eller utan tecken.
För problemet med år 32 768 kan år efter 32 767 tolkas som negativa tal, som börjar med -32 768. Problemet med år 65 536 är mer sannolikt att manifestera sig genom att representera år 65 536 som år 0.
År 100 000
År 100 000 blir det första gregorianska året med sex siffror.
År 275 760
JavaScripts Date API lagrar datum som antalet millisekunder sedan 1 januari 1970. Datum har ett intervall på ±100 000 000 dagar från epoken, vilket innebär att program skrivna i JavaScript med Date API inte kan lagra datum efter 13 september, 275 760 AD.
År 292 277 026 596 problem
Vissa problematiska år inträffar så långt fram i tiden (långt bortom den sannolika livslängden för jorden, solen , mänskligheten och till och med tidigare förutsägelser om universums livstid ) att de huvudsakligen hänvisas till frågor av teoretiskt intresse, skämt eller indikationer på att ett relaterat problem inte är riktigt löst för någon rimlig definition av "löst".
Årsproblemet 292 277 026 596 (cirka 2,9 × 10 11 år i framtiden) kommer att inträffa när 64-bitars Unix-tiden svämmar över efter UTC 15:30:08 söndagen den 4 december 292 277 026 596 AD.
Relativt tidsspill
Microsoft
I Microsoft Windows 7, Windows Server 2003, Windows Server 2008 och Windows Vista lagrades TCP-anslutningsstartinformation på hundradelar av en sekund, med hjälp av ett 32-bitars osignerat heltal, vilket orsakade ett spill och TCP-anslutningar misslyckades efter 497 dagar.
Microsoft Windows 95 och Windows 98 hade ett problem med 2^32 millisekunders rollover i en virtuell enhetsdrivrutin (VTDAPI.VXD), vilket gjorde att systemen hängde sig efter 49,7 dagar.
Boeing
Boeing 787 -flygplanet har haft minst två mjukvaruproblem relaterade till tidslagring. Under 2015 rapporterades ett fel där tiden lagrades i hundradelar av en sekund, med ett signerat 32-bitars heltal, och systemen skulle krascha efter 248 dagar.
År 2020 utfärdade FAA ett luftvärdighetsdirektiv för ett problem där, om flygplanet inte stängs av helt innan det når 51 dagars drifttid, kommer systemen att börja visa vilseledande data.
Arduino
Arduino - plattformen ger en relativ tid via millis()-funktionen. Den här funktionen returnerar ett osignerat 32-bitars värde för "millisekunder sedan start", som är utformat för att rulla över var 49,71:e dag. Som standard är detta den enda tidkällan som är tillgänglig på plattformen och program måste vara särskilt försiktiga för att hantera rollovers. Internt är millis() baserad på att räkna timeravbrott. Vissa energisparlägen inaktiverar avbrott och stoppar därför räknaren från att gå framåt under sömn.
Historiska årsproblem
Även för historiska år kan det finnas problem när man hanterar historiska händelser, till exempel: