Was sollten wir tun, um uns auf 2038 vorzubereiten?

StackOverflow https://stackoverflow.com/questions/36239

Frage

Ich würde gerne glauben, dass ein Teil der Software, die ich heute schreibe, in 30 Jahren noch verwendet wird.Mir ist aber auch bewusst, dass vieles davon auf der UNIX-Tradition basiert, die Zeit seit 1970 als Anzahl von Sekunden anzugeben.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

Die Ausführung führt zu:

  • Do 1. Jan. 00:00:00 1970
  • Sa. 30. Aug. 18:37:08 2008
  • Dienstag, 19. Januar, 03:14:07 Uhr 2038
  • Fr. 13. Dezember 20:45:52 1901

Die Funktionen ctime(), gmtime() und localtime() verwenden alle als Argument einen Zeitwert, der die Zeit in Sekunden seit der Epoche (00:00:00 UTC, 1. Januar 1970;siehe Zeit(3) ).

Ich frage mich, ob es als Programmierer in diesem Bereich etwas proaktives zu tun gibt, oder können wir darauf vertrauen, dass alle Softwaresysteme (auch bekannt als Betriebssysteme) in Zukunft auf magische Weise aktualisiert werden?

Aktualisieren Es scheint, dass 64-Bit-Systeme tatsächlich davor sicher sind:

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}
  • Mi, 31. Dezember 16:00:00 PST 1969
  • Sa. 30. August 12:02:40 PDT 2008
  • Sa. 16. Aug. 23:12:55 PST 292278994
  • So, 2. Dezember, 08:47:04 PST 292269055

Aber was ist mit dem Jahr 292278994?

War es hilfreich?

Lösung

Ich habe einen tragbaren Ersatz für time.h geschrieben (derzeit nur localtime(), gmtime(), mktime() und timegm()), der selbst auf 32-Bit-Rechnern 64-Bit-Zeit verwendet.Es soll als Ersatz für time.h in C-Projekte integriert werden.Es wird in Perl verwendet und ich beabsichtige, damit auch die 2038-Probleme von Ruby und Python zu beheben.Dies ergibt einen sicheren Bereich von +/- 292 Millionen Jahren.

Sie können den Code finden beim y2038-Projekt.Bitte zögern Sie nicht, Ihre Fragen an die zu stellen Issue-Tracker.

Was die Aussage „Das wird in den nächsten 29 Jahren kein Problem sein“ betrifft, lesen Sie hier nach Liste der Standardantworten dazu.Kurz gesagt: Dinge passieren in der Zukunft und manchmal muss man wissen, wann.ich habe auch eine Präsentation über das Problem, was keine Lösung ist und was eine Lösung ist.

Oh, und vergessen Sie nicht, dass viele Zeitsysteme keine Daten vor 1970 verarbeiten.Dinge passierten vor 1970, manchmal muss man wissen, wann.

Andere Tipps

Sie können es jederzeit umsetzen RFC 2550 und sei für immer in Sicherheit ;-)

Das bekannte Universum hat eine endliche Vergangenheit und Zukunft.Das aktuelle Alter des Universums wird in [Zebu] zwischen 10 ** 10 und 2 * 10 ** 10 Jahren geschätzt.Der Tod des Universum ein offenes Universum (der Hitze -Tod des Universums).

 

Y10K -konforme Programme können sich dafür entscheiden, den Bereich der Daten zu begrenzen, die sie unterstützen, die mit der erwarteten Lebensdauer des Universums übereinstimmen.Y10K -konforme Systeme müssen Y10K -Daten von 10 ** 12 Jahren in der Vergangenheit auf 10 ** 20 Jahre in der Zukunft akzeptieren.Y10K -konforme Systeme sollten in der Vergangenheit und Zukunft mindestens 10 ** 29 Jahre annehmen.

Visual Studio ist in Visual Studio 2005 auf eine 64-Bit-Darstellung von time_t umgestiegen (wobei _time32_t aus Gründen der Abwärtskompatibilität weiterhin beibehalten wurde).

Solange Sie darauf achten, Code immer in Bezug auf time_t zu schreiben und keine Annahmen über die Größe zu machen, wird das Problem, wie sysrqb hervorhebt, von Ihrem Compiler gelöst.

Ich denke, dass wir den Fehler belassen sollten.Dann können wir etwa im Jahr 2036 damit beginnen, für große Summen Beratungsleistungen zu verkaufen, um alles zu testen.Schließlich haben wir den Übergang von 1999 auf 2000 nicht so erfolgreich gemeistert.

Ich mach nur Spaß!

Ich saß 1999 in einer Bank in London und war ziemlich erstaunt, als ich sah, wie ein Berater damit begann, die Kaffeemaschine im Jahr 2000 zu testen.Ich denke, wenn wir aus diesem Fiasko etwas gelernt haben, dann, dass die überwiegende Mehrheit der Software einfach funktioniert und der Rest nicht zum Absturz führt, wenn sie ausfällt, und bei Bedarf nach dem Ereignis repariert werden kann.Daher würde ich bis zu einem späteren Zeitpunkt keine besonderen Vorsichtsmaßnahmen treffen.

Angesichts meines Alters denke ich, dass ich viel in meine Rente einzahlen und alle meine Schulden begleichen sollte, also muss jemand anderes die Software anpassen!

Entschuldigung, wenn Sie über den „Kapitalwert“ einer Software nachdenken, die Sie heute schreiben, hat es keinen Einfluss darauf, was die Software im Jahr 2038 tut.Ein „Return on Investment“ von mehr als ein paar Jahren ist für jedes Softwareprojekt ungewöhnlich. Sie verdienen also viel mehr Geld für Ihren Arbeitgeber, indem Sie die Software schneller liefern, anstatt so weit im Voraus zu denken.

Die einzige häufige Ausnahme ist Software, die die Zukunft vorhersagen muss. 2038 ist bereits ein Problem für Hypothekenangebotssysteme.

Führen Sie eine gute Dokumentation und fügen Sie eine Beschreibung Ihrer Zeitabhängigkeiten bei.Ich glaube nicht, dass viele Leute darüber nachgedacht haben, wie schwierig dieser Übergang sein könnte, zum Beispiel werden HTTP-Cookies an diesem Datum nicht mehr funktionieren.

Was sollten wir tun, um uns auf 2038 vorzubereiten?

Versteck dich, denn die Apokalypse kommt.

Aber im Ernst, ich hoffe, dass Compiler (oder genauer gesagt die Leute, die sie schreiben) damit umgehen können.Sie haben fast 30 Jahre Zeit.Ich hoffe, das ist genug Zeit.

Ab wann bereiten wir uns auf das Jahr 10.000 vor?Haben irgendwelche Hardwarehersteller/Forschungslabore nach dem einfachsten Weg gesucht, auf die neue Technologie umzusteigen, die wir dadurch benötigen?

Ich arbeite im Embedded-Bereich und dachte, ich würde unsere Lösung hier veröffentlichen.Unsere Systeme basieren auf 32 Bit, und für die Produkte, die wir derzeit verkaufen, gilt eine Garantie von 30 Jahren, was bedeutet, dass der Jahr-2038-Bug auftritt.Ein Upgrade in der Zukunft war keine Lösung.

Um dies zu beheben, stellen wir das Kernel-Datum 28 Jahre vor dem aktuellen Datum ein.Es handelt sich nicht um einen zufälligen Versatz, 28 Jahre sind genau die Zeit, die benötigt wird, bis die Wochentage wieder übereinstimmen.Ich schreibe dies zum Beispiel an einem Donnerstag und das nächste Mal, dass der 7. März ein Donnerstag sein wird, ist in 28 Jahren.

Darüber hinaus übernehmen alle Anwendungen, die mit Datumsangaben auf unseren Systemen interagieren, das Systemdatum (time_t), konvertieren es in ein benutzerdefiniertes time64_t und wenden den 28-Jahres-Versatz auf das richtige Datum an.

Wir haben eine benutzerdefinierte Bibliothek erstellt, um dies zu bewältigen.Der von uns verwendete Code basiert auf Folgendem: https://github.com/android/platform_bionic

Mit dieser Lösung können Sie sich also problemlos weitere 28 Jahre kaufen.

Bis 2038 sollten alle Zeitbibliotheken 64-Bit-Ganzzahlen verwenden, sodass dies eigentlich keine so große Sache sein wird (bei Software, die nicht völlig ungepflegt ist).

COBOL-Programme könnten jedoch Spaß machen.

Das operative Wort ist „sollte“.

Wenn Sie die Zukunftssicherheit sicherstellen müssen, können Sie Ihre eigene Datums-/Uhrzeitklasse erstellen und diese verwenden. Ich würde das jedoch nur tun, wenn Sie glauben, dass das, was Sie schreiben, auf älteren Betriebssystemen verwendet wird.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top