[D5] Dateidatum wird falsch gelesen

[Bernhard Geyer]

NTFS hat einen grösseren Datumsbereich als Fat. Und mit den richtigen Api bekommt man die auch zu gesicht

[Popov]

Bjoerk und BadenPower

Ich könnte beschwören bei einigen gecrashten Festplatten, Disketten und Sonstigem eine 7 als Dekadenwert gesehen zu haben. Ob es eine 70 oder 7x gewesen ist, weiß ich nicht, aber ich kann mich gut dran erinnern. Auf der anderen Seite hatte ich mich nie genauer damit auseinander gesetzt, somit will ich nichts genau behaupten. Man sollte aber bedenken, das man das Jahr der PC Geburt auf 1976/77 beziffert. Andererseits kam das was man heute allgemein als PC ansieht, wobei es eigentlich nur der IBM-PC kompatible PC ist, 1981 raus. Trotzdem, unsere PCs sind nur die verbesserten Nachbauten des damaligen IBM-PCs. Damit ist anzunehmen, dass Microsoft bei seinem MS-DOS, was eigentlich das 1980 fertiggestellte QDOS von Tim Paterson ist, die Zeitrechnung auf 1980 gesetzt hat. Wobei eigentlich anzunehmen ist, dass das BIOS das Datum liefern sollte. Letztendlich, ich weiß es nicht. Man sollte aber bedenken, dass andere Systeme (vor allem über FTP) durchaus andere Startzeiten haben und vielleicht berücksichtigen einige Programme dies.

Aber wo wir dabei sind, hier der Quellcode der Funktion FileDateToDateTime:

Delphi-Quellcode:

function FileDateToDateTime(FileDate: Integer): TDateTime;
begin
  Result :=
    EncodeDate(
      LongRec(FileDate).Hi shr 9 + 1980,
      LongRec(FileDate).Hi shr 5 and 15,
      LongRec(FileDate).Hi and 31) +
    EncodeTime(
      LongRec(FileDate).Lo shr 11,
      LongRec(FileDate).Lo shr 5 and 63,
      LongRec(FileDate).Lo and 31 shl 1, 0);
end;

Da wird frech 1980 dazu gezählt.

Zitat von Perlsau:

obwohl es ja laut Popov gar nicht möglich ein sollte, ein solches Datum überhaupt erst zu erzeugen bzw. einer Datei zuzuweisen.

Es gibt meiner Kenntnis nach insgesamt 4 Quellen für ein Datum. Das gewöhnliche Time, sowie drei bei TWin32FindData. Time ist Typ Integer, die drei Zeiten bei TWin32FindData sind Longword. Time ist alt, TWin32FindData ist neuer. Vielleicht wird da was anders gespeichert.

[Popov]

Bevor ich nicht schlafen kann, habe ich schnell noch etwas geprogr und bei einer Datei bei FindData (TWin32FindData) die Zeiten auf 0 gesetzt. Rausgekommen ist 1617.

Aber wie gesagt, das sin die Zeiten die in FindData gespeichert sind, nicht die von Time.

[himitsu]

Es gibt Programme, die Prüfen ein Datum auf Gültigkeit und zeigen dann offensichtlich unglütige Datumwerte nicht an.

z.B. gibt Delphi-FindFirst bei 29.03.2015 02:01 eine Fehlermeldung aus, da es erkennt, daß es diese Zeit eigentlich nicht geben kann.
Nachweisbar an zwei meiner Dateien, denn der Rechner hatte die Sommerzeit nicht rechtzeitig umgestellt.
Der Fehler tritt dort auf, weil Delphi die Zeit auf LocalTime umrechnen will und mit dieser Uhrzeit ein kleines Problemchen hat.

So, und jetzt zeig mir mal bitte jemand einen Computer aus dem Jahre 1617.

[Dalai]

Zitat von himitsu:

So, und jetzt zeig mir mal bitte jemand einen Computer aus dem Jahre 1617.

Aber gerne doch: Helpdesk .

MfG Dalai

[Popov]

Zitat von himitsu:

So, und jetzt zeig mir mal bitte jemand einen Computer aus dem Jahre 1617.

http://mathe-abakus.fraedrich.de/abakus/lr/poster02.jpg

[Luckie]

Aber selbst wenn du vom Abakus Dateien auf dem PC kopierst, wirst du kein Dateidatum bekommen welcdhes vor dem Kopiervorgang liegt. Das Erstelldatum ist das Datum wann die Datei auf dem Zielrechner erstellt wurde.

Was anderes sind Daten in Anwendung. Dort können natürlich Daten vor 1980 vorkommen. Stichwort Ahnenforschung.

Und zum Speichern: Natürlich als Integer bzw. Timestamp. Dann kannst du zum Anzeigen das Datum immer passend formatieren. Speicherst du es als String, musst du jedes mal den String parsen, je nachdem wie du es angezeigt haben willst. Stichwort Lokalisierung und verschieden Datumsformate.