Diskussion:Jahr-2038-Problem
Letzter Kommentar: vor 1 Monat von Y2kbug in Abschnitt time_t
Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Jahr-2038-Problem“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.
| Zum Archiv |
| Wie wird ein Archiv angelegt? |
Eigener Artikel[Quelltext bearbeiten]
In diesem Artikel wird von einem verwandten „Jahr-2036-Problem“ berichtet, könnte man dies in einen eigenen Artikel verlagern? --2A02:8109:3EBF:D6AA:40F1:7:F36F:ED41 06:48, 4. Dez. 2023 (CET)
time_t[Quelltext bearbeiten]
Wenn in allen Artikeln rund um das Jahr-2038-Problem auch Unix-time_t genannt wird, dann ist das wohl relevant. Ob eine Software time_t direkt verwenden oder eine andere Variable, die dasselbe Problem hat, und die Zeit aus dem System direkt aus time_t (zu irgend einem Zeitpunkt) bezieht, ist ja eigentlich sekundär, oder nicht?
‣Andreas•⚖ 11:10, 9. Apr. 2024 (CEST)
Nachtrag: es geht um diese Änderungen durch mich und @Brita Beoz:
- Das Problem ist nicht auf Systeme beschränkt, welche time_t benutzen. Das würde nur die Programmiersprache C/C++ umfassen. Selbst da gibt es Probleme, die nicht direkt mit time_t zusammenhängen, z.B. https://bootlin.com/blog/ext2-filesystem-driver-now-marked-as-deprecated/
- Änderung 243849030 von Brita Beoz rückgängig gemacht; Und inwiefern ist ext2 ein Beispiel für "nicht C/C++"? Unter Unix ist time_t ein zentraler ABI-Bestandteil, von daher passte es. Siehe auch z.B. https://www.linux-magazin.de/news/64-bit-time-debian-geht-jahr-2038-problem-an/
- Änderung 243851396 von Y2kbug rückgängig gemacht; Ext2 war ein Beispiel für "selbst bei" C/C++. Inodes verwenden in keiner mir bekannten Implementierung time_t. Ein Beispiel für "nicht C/C++" ist MySQL. 2 Beispiele sollten belegen, dass "beschränkt auf time_t" falsch ist.
Zu den Quellen, siehe die bereits verlinkten im Artikel, u.a.:
- 64-Bit-Time: Debian geht Jahr-2038-Problem an im Linux-Magazin, oder auch z.B.
- OpenBSD 5.5 freigegeben: Jahr-2038-Problem behoben, Zitat: Userspace-Programme interagieren allerdings mit der im OpenBSD-Kernel verwalteten Zeitangabe. Eine Kompatibilitätsschicht fehlt; die Anpassung kann sogar Auswirkungen auf Dateiformate von Programmen haben. Für ältere OpenBSD-Versionen kompilierter Code läuft daher nicht zuverlässig auf dem neuen OpenBSD;
- (Nachtrag zum Nachtrag:) 2038 is closer than it seems, Zitat: The first approach would be to change the 32-bit ABI to use a 64-bit version of time_t (related data structures like, struct timespec and struct timeval would also change). Old binaries could be supported through a compatibility interface, but newly compiled code would normally use the new ABI.
Das sagt für mich aus: egal, welches Konstrukt ein Userspace-Programm verwendet, ob nun C/C++ oder eine andere Sprache, die Zeit holt sich dieses vom System, und dort heißt das Ding "time_t". (Nachtrag zum Nachtrag:) ... und "time_t" scheint Teil des ABI zu sein (siehe LWN-Artikel)...
‣Andreas•⚖ 11:20, 9. Apr. 2024 (CEST)
- Erstmal danke für die Diskussion. Ich bin mit dir absolut einig, dass time_t sehr relevant ist für das 2038-Problem (wir erwähnen das zur Vereinfachung auch in unserem Blog https://beoz.ch/was-ist-der-y2k38-bug-eine-technische-erklaerung/). Ich bin aber der Meinung, dass das Problem nicht auf Systeme mit einer signed 32-bit Definition von time_t beschränkt ist. Wir würden diese Einschränkung in der Einleitung gerne entfernen, damit es Raum für weitere Ergänzungen im unteren Teil gibt. time_t ist relevant, aber nicht ein exklusives Merkmal von Systemen mit dem Jahr-2038-Problem. Es ist eigentlich nicht mal auf Software beschränkt. Entscheidend ist die Repräsentation im Speicher, was mit " vorzeichenbehaftete 32-Bit-Ganzzahl speichern" sehr gut abgedeckt ist. --Brita Beoz (Diskussion) 13:09, 9. Apr. 2024 (CEST)
- Naja, eigentlich hängt das ganze sehr mit Unix zusammen, weil das Datum, von dem losgezählt wird, in etwa das Geburtsdatum von Unix ist. Ich könnte ja mein Programm mit signed integer als 32-Bit-Zahl machen, die am 1.1.2000 loszählt. Dann hätte ich kein Jahr-2038-Problem, sondern ein Jahr-2068-Problem. Oder ich zähle so wie MS-DOS im Dateisystem FAT12/16/32 den Zeitstempel gerechnet hat: in 2-Sekunden-Genauigkeit, dann wäre es ein Jahr-2106-Problem, wenn ich am 1.1.1970 startete...
- Insofern ist der Ausgangspunkt dieser Zahl Unix-spezifisch, und damit direkt "die time_t von Unix".
- Aber das ist natürlich nur meine Interpretation, weshalb wir ja hier diskutieren. Ich hätte es aber eben so verstanden, wenn ich mir die von mir oben (und im Artikel) verlinkten Quellen ansehe.
- Und zum Diskutieren: gerne! Genau für solche Fälle haben wir ja die Diskussionsseiten. Meistens lässt sich damit ein Konsens finden, und meistens wird dadurch der Artikel besser.
- ‣Andreas•⚖ 17:51, 9. Apr. 2024 (CEST)
- Ich habe die von dir verlinkten Artikel natürlich angeschaut, besser gesagt ich kannte sie schon. Besonders der Artikel von Jonathan Corbet aus dem Jahr 2014 ist sehr relevant. Es untermauert die Bedeutung von time_t in diesem Zusammenhang und bereitete die Lösung vor, die 2020 im Linux Kernel 5.10 implementiert wurde. Ich möchte keinesfalls time_t die Relevanz absprechen. Vielleicht versuche ich mal zu begründen wieso ich die kleine Änderung für wichtig halte. Der Satz sagt aus, dass es mit einer 64 bit time_t-Definition in der C-Library kein 2038 Problem mehr gibt. Das ist nachweislich falsch. Wir möchten verhindern, dass daraus falsche Schlüsse gezogen werden. Das Problem liegt ja in der Zukunft und die time_t Problematik wurde im Linux Kernel im Jahr 2020 gelöst. Debian kümmert sich jetzt um ihre spezifischen ABI Probleme, was aber hier (noch) zu weit führen würde um das zu erklären. Wir versuchen also eine gewisse "awereness" für das Ausmass des Problems zu erhalten. Ich versuche mich stark an die bestehenden Fakten zu halten. Die Änderung hat den Sinn des Satzes nicht verändert, sondern nur das Problemfeld auf Systeme mit 64-bit time_t oder ganz ohne time_t erweitert. Um ein bereits verwendetes Beispiel aufzugreifen, Linux ext2 Treiber funktionieren, stand heute, weder auf einem 64-bit Linux noch auf einem 32-bit Linux (ab Kernel 5.10 mit 64-bit time_t) nach dem 19. Januar 2038. Auch das ist natürlich ein Beispiel, was im Jahr 2038 nicht viele Probleme verursachen wird, weil es ja begrenzt und bekannt ist. Ich könnte jetzt noch Anfangen, dass das Jahr-2038-Problem nicht auf EDV-Systeme beschränkt ist, aber ich lasse es mal ;-) Wie sollen wir vorgehen? Du hast dich ja offensichtlich viel mit dem Y2k Problem auseinandergesetzt. Wir kümmern uns seit ein paar Jahren um Y2k38 und sind ein bisschen besorgt. Ich habe nicht erwartet, dass eine kleine Änderung in einem Satz, so schwierig ist. Ich verstehe deine Argumente über die Bedeutung von time_t und teile diese. Trotzdem ist das Problem nicht auf Systeme mit 32-bit time_t beschränkt. Time_t wird im weiteren Artikel noch genügend Raum eingeräumt. Von mir aus kannst du den Satz wieder Rückgängig machen, ich werde es dabei belassen. Davon geht die Welt nicht unter, hoffentlich ;-) Vielleicht versuche ich einen grösseren Beitrag weiter unten zu leisten. --Brita Beoz (Diskussion) 20:58, 9. Apr. 2024 (CEST)
- Danke, das verstehe ich voll und ganz. Ich habe jetzt mal einen Vorschlag gemacht, wie ich mir das in etwa vorstelle, mit diesen Bearbeitungen. Ich hoffe, das zeigt, worauf ich hinaus wollte: es war nämlich nach dem Streichen von time_t in der Einleitung gar nichts mehr davon zu lesen, bis es dann in der Abhilfe plötzlich auftaucht. Da hat mir aber die Erklärung gefehlt -- wo kommt time_t überhaupt her und warum löst sich das Problem nicht einfach, indem man eine der in Abschnitt #Abhilfe erwähnten Wege einschlägt? Hier kommt also die ABI-Kompatibilität ins Spiel, nachdem lang und breit die verwendete Speicherform diskutiert wird, bzw. warum sie oder warum sie nicht einfach umgestellt wurde/werden konnte.
- Ich bin jedoch weiterhin dankbar, wenn dir hier etwas auffällt, das 1. nicht passt, oder 2. noch besser formuliert werden könnte.
- ‣Andreas•⚖ 23:24, 9. Apr. 2024 (CEST)
- @Y2kbug Das finde ich eine sehr gute Lösung. Danke. Ich hab noch eine Änderung vorgenommen. time_t ist ein Datentyp, keine Variable. Ich hoffe das passt, ansonsten gerne ändern. --Brita Beoz (Diskussion) 08:22, 10. Apr. 2024 (CEST)
- Danke! ‣Andreas•⚖ 14:37, 10. Apr. 2024 (CEST)
- @Y2kbug Das finde ich eine sehr gute Lösung. Danke. Ich hab noch eine Änderung vorgenommen. time_t ist ein Datentyp, keine Variable. Ich hoffe das passt, ansonsten gerne ändern. --Brita Beoz (Diskussion) 08:22, 10. Apr. 2024 (CEST)
- Ich habe die von dir verlinkten Artikel natürlich angeschaut, besser gesagt ich kannte sie schon. Besonders der Artikel von Jonathan Corbet aus dem Jahr 2014 ist sehr relevant. Es untermauert die Bedeutung von time_t in diesem Zusammenhang und bereitete die Lösung vor, die 2020 im Linux Kernel 5.10 implementiert wurde. Ich möchte keinesfalls time_t die Relevanz absprechen. Vielleicht versuche ich mal zu begründen wieso ich die kleine Änderung für wichtig halte. Der Satz sagt aus, dass es mit einer 64 bit time_t-Definition in der C-Library kein 2038 Problem mehr gibt. Das ist nachweislich falsch. Wir möchten verhindern, dass daraus falsche Schlüsse gezogen werden. Das Problem liegt ja in der Zukunft und die time_t Problematik wurde im Linux Kernel im Jahr 2020 gelöst. Debian kümmert sich jetzt um ihre spezifischen ABI Probleme, was aber hier (noch) zu weit führen würde um das zu erklären. Wir versuchen also eine gewisse "awereness" für das Ausmass des Problems zu erhalten. Ich versuche mich stark an die bestehenden Fakten zu halten. Die Änderung hat den Sinn des Satzes nicht verändert, sondern nur das Problemfeld auf Systeme mit 64-bit time_t oder ganz ohne time_t erweitert. Um ein bereits verwendetes Beispiel aufzugreifen, Linux ext2 Treiber funktionieren, stand heute, weder auf einem 64-bit Linux noch auf einem 32-bit Linux (ab Kernel 5.10 mit 64-bit time_t) nach dem 19. Januar 2038. Auch das ist natürlich ein Beispiel, was im Jahr 2038 nicht viele Probleme verursachen wird, weil es ja begrenzt und bekannt ist. Ich könnte jetzt noch Anfangen, dass das Jahr-2038-Problem nicht auf EDV-Systeme beschränkt ist, aber ich lasse es mal ;-) Wie sollen wir vorgehen? Du hast dich ja offensichtlich viel mit dem Y2k Problem auseinandergesetzt. Wir kümmern uns seit ein paar Jahren um Y2k38 und sind ein bisschen besorgt. Ich habe nicht erwartet, dass eine kleine Änderung in einem Satz, so schwierig ist. Ich verstehe deine Argumente über die Bedeutung von time_t und teile diese. Trotzdem ist das Problem nicht auf Systeme mit 32-bit time_t beschränkt. Time_t wird im weiteren Artikel noch genügend Raum eingeräumt. Von mir aus kannst du den Satz wieder Rückgängig machen, ich werde es dabei belassen. Davon geht die Welt nicht unter, hoffentlich ;-) Vielleicht versuche ich einen grösseren Beitrag weiter unten zu leisten. --Brita Beoz (Diskussion) 20:58, 9. Apr. 2024 (CEST)