Wie kann eine Datei 1641 'erstellt' worden sein?

Vor ein paar Jahren bin ich auf diese Datei auf unserem Fileserver gestoßen.

Und ich frage mich, wie eine Datei sagen kann, dass sie 1641 erstellt wurde. Soweit ich weiß, wird die Zeit auf dem PC durch die Anzahl der Sekunden seit dem 1. Januar 1970 definiert. Wenn dieser Index ausfällt, können Sie den 31. Dezember 1969 erhalten (der Index sagt wahrscheinlich -1), aber ich bin diesbezüglich ratlos scheinbar zufälliges Datum, das sogar vor der Gründung der Vereinigten Staaten von Amerika liegt.

Wie könnte eine Akte also 1641 datiert werden?

PS: Die Daten sind auf Französisch. Février ist Februar.

Warum ist ein Datum aus dem 17. Jahrhundert möglich?

Windows speichert keine Zeitstempel für Dateiänderungen wie Unix-Systeme . Laut Windows Dev Center (Schwerpunkt Mine):

Eine Dateizeit ist ein 64-Bit-Wert, der die Anzahl der 100-Nanosekunden- Intervalle angibt , die seit dem 1. Januar 1601 (UTC) um 12:00 Uhr vergangen sind . Das System zeichnet die Dateizeiten auf, zu denen Anwendungen Dateien erstellen, darauf zugreifen und darauf schreiben.

Wenn Sie hier einen falschen Wert einstellen, können Sie problemlos Daten aus dem 17. Jahrhundert abrufen.

Eine andere wichtige Frage ist natürlich: Wie wurde dieser Wert festgelegt? Was ist das aktuelle Datum? Ich denke, Sie werden es nie herausfinden können, da dies einfach ein Rechenfehler im Dateisystemtreiber gewesen sein könnte. Eine andere Antwort geht davon aus, dass es sich bei dem Datum tatsächlich um einen Unix-Zeitstempel handelt, der als Windows-Zeitstempel interpretiert wird. Die Berechnung erfolgt jedoch in unterschiedlichen Intervallen (Sekunden vs. Nanosekunden).

In welcher Beziehung steht dies zum Problem des Jahres 2038?

Die Verwendung eines 64-Bit-Datentyps bedeutet, dass Windows (im Allgemeinen) nicht vom Problem des Jahres 2038 betroffen ist , das herkömmliche Unix-Systeme haben, da Unix anfänglich eine 32-Bit-Ganzzahl verwendete, die früher als die 64-Bit-Ganzzahl von Windows überläuft hat. (Dies ist trotz Unix-Betrieb in Sekunden und Windows-Betrieb in Mikro- / Nanosekunden.)

Windows ist natürlich weiterhin betroffen, wenn 32-Bit-Programme verwendet werden, die mit alten Versionen von Visual Studio kompiliert wurden.

Neuere Unix-Betriebssysteme haben den Datentyp bereits auf 64 Bit erweitert, wodurch das Problem vermieden wird. (Da Unix-Zeitstempel in Sekunden ausgeführt werden, liegt das neue Umlaufdatum in 292 Milliarden Jahren.)

Was ist das maximale Datum, das eingestellt werden kann?

Für die Neugierigen - so berechnen Sie das:

• Die Anzahl der möglichen Werte in einem 64-Bit - Integer sind 2 ⁶³ - 1 = 9223372036854775807 .
• Jeder Tick entspricht 100 Nanosekunden, was 0,1 µs oder 0,0000001 s entspricht.
• Der maximale Zeitbereich wäre 9223372036854775807 ⨉ 0,0000001 s , also Hunderte von Milliarden Sekunden.
• Eine Stunde hat 3600 Sekunden, ein Tag hat 86400 Sekunden und ein Jahr hat 365 Tage, also gibt es 86400 ⨉ 365 s = 31536000 s in einem Jahr. Dies ist natürlich nur ein Durchschnittswert, der Schaltjahre, Schaltsekunden oder Kalenderänderungen ignoriert, die zukünftige postapokalyptische Regime den verbleibenden Erdenbürgern diktieren könnten.
• 9223372036854775807 ⨉ 0,0000001 s / 31536000 s ≈ 29247 Jahre
• @corsiKaerklärt, wie wir Schaltjahre abziehen können: 29247/365/4 ≈ 20
• Ihr maximales Jahr ist also 1601 + 29247 - 20 = 30828 .

Einige Leute haben tatsächlich versucht, dies einzustellen und kamen mit dem gleichen Jahr.

Wenn Sie sich nicht schlecht fühlen, wenn Sie raten, lassen Sie mich dies erklären. Und ich meine nicht "jemand hat den Wert auf Unsinn gesetzt", das ist natürlich immer möglich :)

Die Unix-Zeit verwendet normalerweise die Anzahl der Sekunden seit 1970. Windows verwendet dagegen 1601 als Startjahr. Wenn wir also annehmen (und das ist eine große Annahme!), Dass das Problem eine falsche Umrechnung zwischen den beiden Zeiten ist, können wir uns vorstellen, dass das Datum, das eigentlich dargestellt werden sollte, irgendwann im Jahr 2011 (1970 + 41) liegt, was falsch umgerechnet wurde bis 1640 (1601 + 41) . EDIT: Eigentlich habe ich im Windows-Startjahr einen Fehler gemacht. Es ist möglich, dass die tatsächliche Erstellungszeit im Jahr 2010 lag oder dass ein anderer Fehler aufgetreten ist (Off-by-One-Fehler sind in der Software ziemlich häufig: D).

Angesichts der Tatsache, dass dieses Jahr zufällig ein weiteres Tracking-Datum für die betreffende Datei ist, halte ich dies für eine ziemlich plausible Erklärung :)

Wie von anderen geschrieben, ist die Windows-Epoche am 1601-01-01 00:00 .

Die Anzahl der Sekunden zwischen dieser Epoche und der angezeigten Dateizeit beträgt 1.266.705.294 .
Wenn wir das zur Unix-Epoche hinzufügen, erreichen wir am Samstag den 20.02.2010 um 23:34:54 Uhr MESZ . Dies ist ungefähr ein Jahr vor dem letzten Zugriffsdatum, was es einigermaßen plausibel macht. Es könnte sich also um einen Unix-Zeitstempel handeln, der gegen die falsche Epoche interpretiert wurde.

Wie für diese Art von Fragen üblich, hat Raymond Chens Blog eine Antwort auf diese Frage aus dem Artikel "Warum ist die Win32-Epoche am 1. Januar 1601?". Eintrag vom 6. März 2009:

Die FILETIMEStruktur zeichnet die Zeit in 100-Nanosekunden-Intervallen seit dem 1. Januar 1601 auf. Warum wurde dieses Datum gewählt?

Der Gregorianische Kalender arbeitet in einem 400-Jahres-Zyklus, und 1601 ist das erste Jahr des Zyklus, der zu dem Zeitpunkt aktiv war, als Windows NT entworfen wurde. Mit anderen Worten, es wurde gewählt, um die Mathematik gut zu machen.

Ich habe tatsächlich die E-Mail von Dave Cutler, die dies bestätigt.