Es ist noch einige Tage hin, aber im Jahr 2038 könnte es arge Probleme mit Unix sowie Software, die das Unix-Zeitformat nutzt, geben. Denn am 19. Januar 2038 läuft um 03:14:07 UTC die 32-Bit-Integer-Zeitdarstellung, die unter Unix verwendet wird, über. Das könnte, wie beim Y2K-Problem zur Jahrtausendwende, dazu führen, dass Software, die auf dieser Zeitdarstellung basiert, nicht mehr funktioniert. Der Hintergrund des Year 2038-Problems ist in der Wikipedia beschrieben. The Register weist aktuell hier auf diesen Sachverhalt hin.
Suchen
Blogs auf Borncity
Spenden
Den Blog durch Spenden unterstützen.
Links
Seiten
Amazon
Awards
MVP: 2013 – 2016
WIMVP: 2017 – 20202015
Blogroll
Soziale Netzwerke-Seiten
Foren
Um mir den Moderationsaufwand zu ersparen, empfehle ich eines der unter Websites verlinkten Angebote. Im Microsoft Answers-Forum bin ich gelegentlich noch als Moderator zu Windows-Themen unterwegs.
Neueste Kommentare
- Bastian bei Veeam Backup & Replication 12.3.2.4165 Patch nicht installierbar?
- Visitator bei OTA-Update legt Hybrid-Jeeps während der Fahrt still
- DS2 bei Veeam Backup & Replication 12.3.2.4165 Patch nicht installierbar?
- DS2 bei Veeam Backup & Replication 12.3.2.4165 Patch nicht installierbar?
- Michael bei Veeam Backup & Replication 12.3.2.4165 Patch nicht installierbar?
- R.S. bei OTA-Update legt Hybrid-Jeeps während der Fahrt still
- Anonym bei Sicherheitsprobleme: AI-Browser; Oracle 0-day; GoAnywhere; Ivanti; 7-Zip etc.
- Hans van Aken bei OTA-Update legt Hybrid-Jeeps während der Fahrt still
- Luzifer bei Sicherheitsprobleme: AI-Browser; Oracle 0-day; GoAnywhere; Ivanti; 7-Zip etc.
- Kfr bei Österreichs Datenschutzbehörde: Microsoft 365 Education trackt Schüler illegal
- Warum bleiben? bei Host Europe: cPanel-Migration, ein Erfahrungsbericht
- Thorsten M. bei Betriebssystem/Windows Verteilung (Ende Sept. 2025)
- Kfr bei Microsoft 365 Apps gestört? (13. Okt. 2025)
- Wissender bei Veeam Backup & Replication 12.3.2.4165 Patch nicht installierbar?
- Carsten bei Neuauflage des Google Newsgroup-Spam?
Ich glaub bis dahin gibt es die nötigen Updates bzw. neue Distributionen um das zu beheben.
Dieser Punkt sollte hier nicht weiter diskutiert werden – es ist Spekulation, was passiert.
Das Problem könnte schneller auftauchen als gedacht wenn z.B. langfristige Finanzierungen mit Linux berechnet werden die über das Jahr 2038 hinausgehen.
Betrifft das nicht nur DEC PDP 11 Maschinen?
Nein, die HP3000 aus dem Jahr 1992, welche hier noch im Keller steht, trifft es schon am 1. Januar 2027. :‑)
https://3000newswire.blogs.com/3000_newswire/2007/01/index.html#a0015553963
Das Problem existiert nur bei alten 32-Bit-Systemen, auf allen anderen Systemen ist time_t längst auf 64 Bit umgestellt. Das betrifft also nur noch Altsysteme und diverse IoT- und Embedded-Geräte, die bis 2038 dann vermutlich längst verschrottet sind.
Das Problem betrifft nicht nur das Betriebssystem, sondern z.B. auch Datenbanken und Anwendungsprogramme. Letztendlich alles, was den 32-bittigen Timestamp des Betriebssystems für interne Zwecke verwendet. Wobei man auch noch mal zwischen vorzeichenbehafteter und vorzeichenloser Auswertung unterscheiden muß – unsigned tritt das Problem erst im Jahr 2106 auf.
Lässt sich sowas nicht mit unkritischen Systemen testen?
Einfach mal Datum und Uhrzeit vorstellen.
Bereits im Juni 2018 waren alle kernel patches dafür gemerged
Das Problem dürften weniger PC / Laptops sein, bis dahin sind die Linux-Systeme definitiv entsprechend angepasst.
Spannender wirds bei Appliances oder embedded Systems, die nicht oder nur mit Aufwand aktualisiert werden können.
Hier mal ein Beispiel für Fernseher (die Meisten dürften 2038 nicht mehr aktiv sein, andere Appliances oder IOT-Geräte aber durchaus): https://jahr-2038-problem.de/2023/obsoleszenz-fernseher-2038/
Das Y2k Problem wurde auch hochgehyped bis hin zum Weltuntergang und war dann nur ein laues Lüftchen… ;-P
Weil genügend investiert worden war
y2k wurde von manch Anbietern
missbraucht dem Kunden noch ein Update unterzujubeln, obwohl ihre Software bereits sauber programmiert war, natürlich kostenpflichtig.
Problematisch war Software die mit einer BCD Kodierung arbeitete.
Denen fehlte ein Nibbel.
Damit war Microsoft sogar noch 2022 (?) rein gefallen, die so ihre Virensignaturen datiert hatten.
Das Y2k-Problem war real und weit verbreitet. Nur durch rechtzeitige und stetige Erinnerung daran hat es die Welt dann auch geschafft die Systeme rechtzeitig anzupassen. Spätestens als die Banken anfingen ihre Geschäftskunden anzuschreiben um diesen klar zu machen, dass nichts machen das wirtschaftliche aus bedeuten könnte.
Eine gewisse Spannung war am 31.12.1999 da. Man wartete auf die ersten Meldungen ob in Sydney die Computersysteme noch funktionieren. Es ging gut, die allermeisten rund um den Erdball hatten ihre Hausaufgaben gemacht.
Für die jüngeren Leser, speziell für @Luzifer zum nachlesen – so "ein laues Lüftchen" war das nicht:
https://de.wikipedia.org/wiki/Jahr-2000-Problem
Ich bin nicht jünger… gehöre wie der Blog Eigner in die selbe Generation… nur mal am Rande. Ich habe noch Lochstreifen gecodet!
User der Stunde Null!
Und ich war dabei am 31.12.1999 in New York! Und es war ein laues Lüftchen im Vergleich zu dem Panik Hype der gemacht wurde, da feierte man Weltuntergang… vor lauter Panik die verbreitet wurde und dann war nix.
JA das Problem existierte und ja man musst was tun! Die Panikmache war aber vollkommen übertrieben und unnötig! Ebenso wie jetzt 2k38.
Es kann Probleme geben wenn man nix tut… mehr aber auch nicht!
Da bricht nix zusammen, da geht die Welt nicht unter.
Und ein Großteil ist längst schon gepatcht… ist halt so, der Blog lebt von Panik! Panik vor Phishing, Panik vor Malware usw. alles zeugs vor dem man keine Angst haben muss wenn man Brain2.0.exe auch nutzt und nicht brachliegen lässt.
Gefahren haben wir viele, (aktuell sogar Große) mit IT haben die jedoch nix zu tun. Was glaubt ihr alle wohl weshalb wir die Wehrpflicht wieder einführen wollen? Macht nix auf dem Gebiet bin ich gut ausgebildet und hab 16 Jahre praktische Einsatzerfahrung. Das verlernt man nicht ;-P
Legio Patria Nostra!
Muss Dich enttäuschen… das patchen von Kabelverbindungen und drehen von Rädchen in einem (Front)Panel…. das war Stunde Null ;-)
Habe da mal einen historischen Abriß zu geschrieben:
https://blog.jakobs.systems/blog/20230628-linux-cli/
In der Multics Welt (Vorgänger von Unics, bzw. Unix) ist das Jahr 2043 eher ein Problem. Ab dann kommt es im Dateisystem zu Überlauf und Kollisionen von 36-bit UIDs:
https://multics-wiki.swenson.org/index.php/Design_Limitations:_How_Long_can_Multics_Run%3F
Doppeltes AUTSCH: die Stunde 0 eingeläutet haben mechanische "Spielzeuge" wie beispielsweise die "Analytical Engine" von Charles Babbage.
Durch (Um)Verdrahtung programmierte Elekronen"hirne" kamen ETWAS später, noch nach den per Film- oder Lochstreifen programmierten Maschinen.
Per Drehwähler oder Schalter programmierbare Maschinen, deren Programm in ihrem (Arbeits-)Speicher hinterlegt war, kamen noch später auf.
Challenge accepted ;-)
Es geht um einen "User der Stunde Null!" wie der Vorposter für sich beanspruchte, einer zu sein. Also Anwender ohne tiefergehende Systemkenntnis, die etwas "bedienen".
Und das waren dieser Kontextualisierung zufolge User, die …
a) weiblich
b) britisch
c) während des 2. Weltkrieges im Chain Home Projekt
…tätig waren
Die mechanischen Geräte von Babbage, die programmierbaren Webstühle und frühen Zählmaschinen von Hollerith sind da raus. Die konnten sallopp gesagt nur Löcher zählen, keine universellen Programme ausführen.
Das schaffte erst später Konrad Zuse mit seiner Z3… wobei nicht überliefert ist, ob es da User gab. Aber das ist eine andere, traurige Geschichte und ein weiterer Grund, niemals dämliche Nazis in irgendwelche entscheidenden Posten und Positionen zu setzen.
Alles richtig!
Ich habe die mechanischen Maschinen mit vollster Absicht der Stunde 0 zugeordnet, da sie nicht universell "rechneten".
JFTR: Jacquard-Webstühle haben ihre Programme von externen Speichermedien abgelesen.
Dafür, dass du nicht jünger bist, verhältst du dich hier aber trotzdem wie ein Kleinkind…
Deine Art zu schreiben liest sich wie die eines Teenagers (oder Boomers, der unbedingt "cool" sein will)
Ich halte dieses Zeitformat schon lange für obsolet. Weder die Zeit als solche, noch die von Unix begann am 1. Januar 1970. Mühselig müssen in den Config Dateien die Zeitformate manuell angepasst werden, damit Zeiteinträge in Logfiles lesbar werden. Oder man muss diese mühselig durch Excel umrechnen lassen.
Das schreibt offenbar jemand, der von Unix oder Linux wenig bis keine Ahnung hat. Die timezone regelt das für jede erdenkliche Lokalzeit. Ein Unix oder Linux Experte würde niemals Excel dafür verwenden.
Geht es gar nicht mehr ohne persönliche Angriffe?
Warum wird die Zeit nicht standardmäßig "lesbar" in die Logfiles geschrieben?
Und wie, wenn nicht mit Excel, wertet man eine Log Datei aus um sie z.B. Auditoren etc. zur Verfügung zu stellen?
Betr. "Und wie, wenn nicht mit Excel, wertet man eine Log Datei aus um sie z.B. Auditoren etc. zur Verfügung zu stellen?":
Da musst Du Dich mal an den Foristen Luzifer wenden. Weiss alles, kann alles und ist vor allem ein Mann der Stunde Null – als es noch kein Excel gab. Wenn Du wie er 16 Jahre Einsatzerfahrung hättest, könntest Du die Auditoren auch mal mit vorgehaltener Waffe davon überzeugen, dass Logs doch eigentlich gar nicht so wichtig sind.
Ironie aus, im Ernst: Wenn Du ohne Excel keine Logfiles auswerten kannst, hast Du als Informatiker schwerste Defizite. Mach wass dagegen, die KI ist Dein Freund.
Stammt halt aus einer Zeit, als noch jedes Byte zählte. Ja, sollte obsolet sein. Aber Jira z.B. speichert auch heute noch die Aufwandsschätzungen in Sekunden — das muss man auch immer erst um-exceln, wenn man etwas damit anfangen möchte…
Betr. "das muss man auch immer erst um-exceln,":
Noch so 'n Vollblutinformatiker, der ohne Excel aufgeschmissen ist. Leute wie Du sind der Grund, warum Deutschland zur Microsoft Office Hölle geworden ist.
Ich bin durchaus beeindruckt von Leuten, die spontan erfassen können, welcher Aufwand sich hinter 2419200 Sekunden verbirgt. Ich selbst bin leider zu blöd dazu und muss daher auf technische Hilfsmittel zurückgreifen.
Und die Reihe Dir zur Verfügung stehender Hilfsmittel beschränkt sich auf Excel? Na sauber!
Excel (privat übrigens nicht wirklich Excel, sondern Planmaker) ist für mich ein universelles Tool, mit dem ich tatsächlich seit vielen Jahren unter anderem so ziemlich alles, was im Bereich Projektmanagement an Controlling-Aufgaben anfällt, sehr gut lösen kann. Dass es nicht das einzige Hilfsmittel ist, das ich verwende, siehst Du z.B. an meiner Erwähnung von Jira.
Aber ich lerne gern dazu.
Mit welchem Tool würdest Du folgende (in meinem Umfeld ziemlich alltägliche) Aufgabe lösen: Mittelgrosses Projekt (also ca. 30-70 Mio. Euro), zwei oder drei Jahre Laufzeit, ca. 200 Epics und 5000 Stories (beides in Jira). Jede Story ist mit einer Aufwandsschätzung versehen und hat einen Workflow hinterlegt. Jeder Status des Workflows ist mit einer prozentualen Zielerreichung verknüpft, also z.B. Status1 = 0%, Status2=10%, Status3=60% usw.
Gewünscht: Monatlich für jedes Epic, aufsummiert über die Stories, die aktuelle Zielerreichung und grafische Darstellung derselben. Grafischer Vergleich der Gesamt-Zielerreichung (also aufsummiert über alle Epics) mit den Vorperioden, mit dem Planbudget und mit dem Ist-Budget. (Letzteres beides aus SAP, übrigens angeliefert in Form einer Excel-Datei (!) mit "PT" und "Euro" statt "Sekunden".)
Bin ehrlich gespannt.
Ohne Scheiß: Für genau solche Szenarien:
Bash, curl, awk, sed und Visidata
https://www.visidata.org/
Wozu hat Dein Jira eine Web API? Das ständige Rumklickern, die langsamen Ladezeiten und hin und her schubsen von Dateien würde mich aufregen. Wobei bei nur 5000 Datensätzen (süß) Du vermutlich kaum einen Unterschied spürst. Arbeite erstmal mit hunderttausenden von Datensätzen oder Mio. Öffne eine solche CSV in Excel und vergleiche mit visidate. Das sind Welten!
Hier ein Einstiegstutorial damit Du siehst, wie effektiv Du mit mit dem richtigen Tool für ein Szenario bist:
https://jsvine.github.io/intro-to-visidata/
Hey, danke für den Input.
Ich habe mir die Einführung mal angeschaut, und habe den Eindruck, dass es sich hier um eine Art sehr rudimentäres Ad-hoc-Pivot-Tool handelt, das nur einen winzigen Bruchteil der Berechnungs- und Darstellungsmöglichkeiten eines Excel (oder Planmaker, oder Calc, oder …) bietet. Mehr behauptet es ja auch gar nicht zu sein ("VisiData is a free, open-source tool that lets you quickly open, explore, summarize, and analyze datasets in your computer's terminal"). Von daher ist mir nicht klar, wo nun der Mehrwert liegen soll?!?
Aber ich glaube, mittlerweile sind wir auch ein bisschen sehr off-topic…
naja du wünschstest nichts anderes als monatliche Status-Berichte. "Aufsummieren" hast Du gesagt. Alles, was absehbar mehr als 3x zu machen ist automatisiere ich weg.
Mit dem aktuellen Debian 13 wurde ein Großteil der Software-Pakete, die über die regulären Debian-Repositories bereitgestellt werden, bereits gepatched sodass die 64-Bit time_t -Varianten genutzt werden.
Nur bei der 32-Bit x86-Variante wurde es nicht gepatched. Aber die 32-Bit-Version ist mit Trixie auch aus dem regulären Debian-Support gefallen.
Vgl. auch https://wiki.debian.org/ReleaseGoals/64bit-time
Es ist eher wahrscheinlich, dass es 2036 beim NTP Epochwechsel zu Problemen kommen wird als 2038.
Alle heutigen Unix/Linux Systeme sind spätestens seit 2019 mitigiert.
Betr. "Alle heutigen Unix/Linux Systeme sind spätestens seit 2019 mitigiert.":
Völliger Unsinn. Befremdlich, welcher Nonsens hier im Forum unbehelligt verbreitet werden darf. Nur zwei Beispiele, dass von "spätestens seit 2019" überhaupt keine Rede sein kann: BusyBox ist erst seit Ende 2024 (1) und FreeBSD (2) erst seit Anfang 2025 vorbereitet. Im übrigen sind die Applikationen spielentscheidend.
(1) https://www.theregister.com/2024/10/04/busybox_137/
(2) https://reviews.freebsd.org/D48711
und genau weil alles seit 2019 migriert ist weist Debian in den aktuellen Release Notes des diesen Monat herausgekommenen stable unter Punkt 2.2.6 darauf hin, dass nun endlich alle unterstützten Architekturen die 64-bittige time_t ABI nutzen (außer i386, das aber nur noch für legacy-Anwendungen und multiarch o.ä. gedacht ist).
Zudem weisen sie unter 5.1.9, darauf hin dass genau wegen des Y2k38-Problems die Befehle last, lastb und lastlog nicht mehr funktionieren bzw. die von diesen Programmen genutzten /var/log/wtmp, /var/log/btmp, /var/run/utmp und /var/log/lastlog ein Format haben, das dazu nicht genügend Speicher vorsieht (und die Entwickler sich weigern, dieses Format anzupassen) – und deshalb entfernt wurden.
Mag sein, dass es im Kernel schon eine Weile angepasst ist – das Kern-System "außenrum" hat(te) noch einige solcher Altlasten.
FYI: Von 1999 auf 2000 war kein Jahrtausendwechsel, aber es wurden Y2K-probleme befürchtet.
Erst mit 1.1.2001 hat das neue Jahrtausend begonnen, da es in unserer Zeitrechnung kein Jahr 0 gibt.
Ja, guter Hinweis – vielen Dank. Haben sicherlich viele nicht (so) auf dem Schirm.
Da sind wir wieder bei den umgangsprachlichen vs. korrekten Bezeichnungen …
Auszug Google KI:
"Der Jahrtausendwechsel ist nicht einheitlich definiert; er bezieht sich zum einen auf den Übergang zum neuen Jahrtausend im Jahr 2000, der in der Populärkultur gefeiert wurde, zum anderen, und das ist mathematisch korrekt nach dem proleptischen Gregorianischen Kalender, auf den 1. Januar 2001, da es kein Jahr null gibt und das erste Jahrtausend am 1. Januar (Anmerkung: im Jahr) 1 begann."
Ist das gleiche Thema wie "Pedelec" vs. "E-Bike". Alle Leute reden von E-Bikes, meinen aber (technisch korrekterweise) Pedelecs …
(Ein Pedelec ist KEIN E-Bike, aber ein E-Bike ist auch ein Pedelec)
"Sagen" und "Meinen" …
Auch ein gutes Beispiel aus dem Alltag: "Strompreis: 40ct je kWh" .. finde den Fehler!
Die physikalische korrekte Einheit für Strom ist A (Ampere), nicht kWh (Kilowattstunde (hier elektrische) Energie)).
Korrekt müsste es also heißen. "(elektr.) Energiepreis: 40ct/kWh" … macht aber niemand, selbst im TV (auch öffentlich-rechtlicher) wird es falsch bezeichnet.
Und sowas brennt sich dann (falsch im Kopf) ein, leider.
Aber das ist der Alltag umd Umgangssprachlichkeit … 😁
Aber unabhängig davon … das 2038-Unix/Linuxproblem ist
1. noch etwas zeitlich in der Zukunft
und
2. hoffen alle, das die Leute, die da in den Thema drinstecken, das bis dahin gefixed haben.
Und nach meiner Einschätzung: Otto-Normalo wird es im privaten nicht tangieren …
Meiner Meinung nach kann das übel enden wenn IoT Geräte reihenweise auf die Nase fallen.
Die Menge an IT-Geräten hats ich seit 1999 ver X-facht ohne das nennenswert auf Qualität geachtet wurde.
Gruß
Wenn die IoT-Geräte "TEMU", "Shein" und "AliExpress-Qualität" haben, halten die nicht mal bis 2030 … also .. alles entspannt in 2038, zumindest was das Kernthema dieses Artikels angeht …
Und wer sich privat IoT ins Haus holt … selbst gewähltes Elend!
Je weniger (angeblich so) "intelligente und smarte" Technik im Haus, umso besser … Meine Meinung.
2037, nach den Herbstferien, kann man mal drüber nachdenken. Ein Glück bin ich da schon 10 Jahre in Rente. Oder zu Staub zerfallen.
Ich bin auch der Meinung, dass es wenig Anlass zu großer Besorgnis gibt. Dennoch sind viele Kommentare hier am Thema vorbei. Es geht nicht darum, ob irgendwelche Kernel das schon seit 20xx berücksichtigt haben. Es gibt draußen in der Industrie und öffentlichen Infrastruktur Geräte, die laufen Jahrzehntelang zuverlässig und haben und werden nie ein Update sehen. Es ist vermutlich nicht wahrscheinlich, dass ein System, dass eine Hebebrücke steuert, am Datum scheitert. Aber von seinem Desktop OS auf den Rest der Welt zu schließen ist halt auch Käse. ;)
Wer eine (Microsoft?) PKI betreibt, wird übrigens auch feststellen, dass die Root Zertifikate im Jahr 2038 (unabhängig von der eigentlichen Laufzeit) nicht mehr gültig sind. Falls jemand dann nicht aufpasst und sich auf die Gültigkeit der davon abhängigen Zertifikate (automatische Renewals) verlässt, könnte auf die Nase fallen. Die ausgestellten Zertifikate können auch gerne längere Laufzeiten anzeigen. Sie werden aber ungültig sein.