[D5] Dateidatum wird falsch gelesen

[JanWe]

Hallo,

ich hab gerade festgestellt, daß das Dateidatum falsch ausgelesen wird.
und zwar wird das z.B. bei einem (LastChange)Dateidatum vom 1.1.1970 2:22:13 in der Variablen SearchRec.time gar nicht aktualisiert. Es wird [in der Schleife] einfach das des vorherigen beibehalten, bis wieder eine Datei mit einem gültigen Datum kommt.

Was kann ich denn tun?
ich mein - der Dateimanager zeigt doch auch das richtige Datum (1.1.1970) an?

Kann vielleicht einer eine Lösung für Delphi5 geben?
(Weiß ja nciht, ob die neuren Delphi's das schon alles nicht mehr müssen ....)

Delphi-Quellcode:

procedure GetAllFiles2(mask: string);
var   searchRec: TSearchRec; begin
  if FindFirst(mask, $23, search) = 0 then
  begin
     repeat
       nummer := nummer + 1;
       Form1.MeinARray[Nummer].DTime := FileDateToDateTime(searchRec.time);
     until FindNext(searchRec) <> 0;
end;end;

Delphi-Quellcode:

  // Unterverzeichnisse scannen
  if FindFirst(directory + '*.*', faDirectory, search) = 0 then
  begin
    repeat
      if ((search.Attr and faDirectory) = faDirectory) and (search.Name[1] <> '.') then
        GetAllFiles(directory + search.Name + '\' + ExtractFileName(mask));
    until FindNext(search) <> 0;
    FindClose(search);
  end;

und wo ich schon einmal dabei bin ... ich möchte das Dateidatum auch möglichst präzise als NICHT-Rational speichern (am besten als was ganzzahliges)
also hab ich das mal mit z.B: 100.000 mal genommen und wollte dann alle Reste abschneiden.

FullTIME := trunc(100000 * FileDateToDateTime(search.time));
Dummerweise wird FullTime dann aber negativ.
Kennt jemand noch ne andere Möglichkeit das Dateidatum irgendwie als Zahl
und später auch als String exportier und zurück importierbar zu speichern?

Danke Euch. Wäre wirklich nett.

[Luckie]

Hä? Wie liest du es denn aus? Welches Betriebssystem? Welches Dateisystem? Hast du auch die benötigten Rechte?

[JanWe]

Zitat:

Zitat von Luckie (Beitrag 1298094)

Hä? Wie liest du es denn aus? Welches Betriebssystem? Welches Dateisystem? Hast du auch die benötigten Rechte?

Guten Morgen,

...hab den Code oben noch etwas um ne Aufrufprozedur ergänzt.

Windows 7 64 Bit
standard (NTFS)
Rechte: Ja, eigenes Unterverzeichnis im Programmverzeichnis auf ner anderen Partition. Haben alle Programme Schreibrechte.


Ich vermute allerdings eher, daß Delphi intern damit nicht klarkommt.(das alte aber geliebte Delphi 5)

Also wenn ich das alle gescanneten Dateidaten mit Datum (formatiert, dahinter als Integer) ausgeben lasse, sieht man, daß ab Datei 05 [eigentlich 1.1.1970] das Datum von 04 übernommen wird und bei 05 Vorschlag - nochmal .jpg und - sehe ich gerade - sogar bis 06...GIF übernommen und selbst beim 06 nicht durch neue ersetzt wird.

Delphi-Quellcode:

0*Dateiname .... gelesenes Datum|Uhrzeit ..Filedate*10000 .... Dateigröße
01 Datei1.txt   04.12.2013   21:15:08   416128855   80171
02 Info.doc   07.04.2015   00:01:08   421010007   63091
03 Rechnung. xls   12.01.2015   21:09:38   420168816   487258
04 Alternativ.txt   12.09.2014   08:22:10   418943487   3735
05 Vorschlag.jpg   12.09.2014   08:22:10   418943487   24149
05 Vorschlag - Kopie.jpg   12.09.2014   08:22:10   418943487   24149
05 Vorschlag - nochmal .jpg   12.09.2014   08:22:10   418943487   24149
06 test.GIF   12.09.2014   08:22:10   418943487   5863
07 Briefumschlag.png   09.01.2015   23:13:30   420139677   242816
spi-curious-htr0061.jpg   08.12.2010   00:52:56   405200367   24039

kommt folgendes
alle 05 sind Kopien derselben - und haben alle das selbe LastChange Dateidatum 1.1.1970. Die 06.GIF hat 12.9.2014
ich hab fast allen Dateinamen eine 0Zahl vorangestellt, damit man sie (im Debugger) besser unterscheiden kann

[Popov]

Zitat:

ch möchte das Dateidatum auch möglichst präzise als NICHT-Rational speichern (am besten als was ganzzahliges)
also hab ich das mal mit z.B: 100.000 mal genommen und wollte dann alle Reste abschneiden.

FullTIME := trunc(100000 * FileDateToDateTime(search.time));
Dummerweise wird FullTime dann aber negativ.

Teste das mal:

Delphi-Quellcode:

var
  DateTime: TDateTime;
begin
  DateTime := 0;
  ShowMessage(DateTimeToStr(DateTime));

Ergebnis wird sein: 01.01.1900 minus eine Sekunde. Datum 0 ist also dieses Datum.
Was willst du also mit mal 100000 erreichen. Bedenke, Zeit 0 * 100000 ergibt 31.12.1899, ein Tag später mal 100000 ergibt das Datum 14.10.2173. Heute sind seit der Zeit 0 42111 Tage vergangen. Jede ganze Zahl steht für einen Tag. Also Now + 1 ergibt als Datum morgen. Nachkommastellen sind Uhrzeit. Wenn ich also Heute (42111) mal 10000 nehme, ergibt das 4211100000 Tage. Mal grob berechnet ergibt das 1900 + (4'211'100'000 / 356,25) etwa 11 Millionen Jahre in der Zukunft.

[Bjoerk]

Zitat:

Zitat von JanWe (Beitrag 1298092)

[..] und wo ich schon einmal dabei bin ... ich möchte das Dateidatum auch möglichst präzise als NICHT-Rational speichern (am besten als was ganzzahliges) [..]

SearchRec.Time ist bereits ein Integer :wink:

[JanWe]

ja, kann sein, daß die das bei den höheren Versionen schon geändert / präzisiert haben.

hier hab ich noch [nach FileDateToDateTime();]
41612,8855092593
für
04.12.2013 21:15:08

[Popov]

Zitat:

Zitat von JanWe (Beitrag 1298197)

ja, kann sein, daß die das bei den höheren Versionen schon geändert / präzisiert haben.

hier hab ich noch [nach FileDateToDateTime();]
41612,8855092593
für
04.12.2013 21:15:08

Präzisiert wird gar nichts. Wo kommen wir dahin, wenn in einer Delphi-Verison eine Funktion ein Ergebnis liefert, in einer höheren Version etwas anderes. Wenn, dann kommt einen andere Funktion dazu, aber jede Funktion sollte immer das gleiche Ergebnis liefern. Egal welche Version.

Was aber Bjoerk meinte war nicht das Ergebnis der FileDateToDateTime Funktion, sondern von Search.Time. Das ist Integer. Dieser Integerwert wird mit der FileDateToDateTime in das Delphi Format konvertiert. Und das ist ein Double Wert. Die Vorkommastellen präsentieren das Datum, die Nachkommastellen die Zeit. Die Formel ist einfach: 1 / 24 / 60 / 60 / 1000. 1 ist der Tag. Du kannst dir also aussuchen was die 1 bedeutet, entweder 1 Tag oder 24 Stunden. Ist das Gleiche. Also 1 Tag / 24 Stunden/ 60 Minuten / 60 Sekunden / 1000 Millisekunden. Wobei bei dem Millisekunden Delphi schon ungenau ist. Was die Stunden, Minuten und Sekunden angeht, da stimmt alles.

//Edit:

Der maximale positive Wert von Integer ist 2147483647. Bei Longword ist es 4294967295. Aber bleiben wir bei Integer.

MaxInt ist bei Integer also 2147483647, bzw. 2'147'483'647. Das sind 10 Zeichen. Now, bzw. Date, also der heutige Tag hat den Wert 42111, bzw. 42'111. Multiplizieren wir also den heutigen Tag mit 100000, bzw. 100'000, ist das Ergebnis 4211100000, bzw. 4'211'100'000. Der Wert ist also höher als der von Integer. Bei Logword hättest du da noch etwas Platz, aber nur für 838 Tage. Du solltest dich also mit deinem Programm beeilen, vorausgesetzt du nutzt Longword. Warum ist dein Wert aber negativ? Weil Integer den Bereich -2147483648..2147483647 hat. Das letzte Bit ist für das Vorzeichen. Wird es überschrieben, wird der Integer negativ. Die Idee mit der Multiplikation ist nicht optimal.

Ich könnte dir nun vorschlagen es auf eine andere Art zu speichern, das wird aber auch knapp. Der Grund könnte daran liegen, dass das Delphi Datum am 01.01.1900 anfängt, das Datum von Dateien (soweit ich es weiß) am 01.01.1970. Das sind 25567,5 Tage unterschied. Das spart paar Bit.

Aber nur falls du es dennoch so machen willst, Delphi kennt inzwischen Int64. Das könnte mit deinem Wert umgehen.

Delphi-Quellcode:

var
  i64: Int64;
  DateTime: TDateTime;
begin
  i64 := Trunc(Now * 100000);
  ShowMessage('Int64 = ' + IntToStr(i64));
  DateTime := i64 / 100000;
  ShowMessage('Daum und Zeit nach der Umrechnung = ' + DateTimeToStr(DateTime));
end;

Nur weiß ich nicht ob D5 schon Int64 hat.

[Dalai]

Zitat:

Zitat von Popov (Beitrag 1298205)

Nur weiß ich nicht ob D5 schon Int64 hat.

Hat es.

Ich würde mir SearchRec sparen und stattdessen mit FindFirstFile und dem von dieser Funktion gefüllten TWin32FindData arbeiten. Der Zeitstempel ist dort zwar gesplittet in Hi- und Low-Wert, aber da es genügend Beispiele im Netz zu FindFirstFile gibt, sollte das kein Problem sein.

MfG Dalai

[BadenPower]

Zitat:

Zitat von JanWe (Beitrag 1298092)

Kennt jemand noch ne andere Möglichkeit das Dateidatum irgendwie als Zahl
und später auch als String exportier und zurück importierbar zu speichern?

Warum nimmst Du nicht gleich den Integerwert aus "searchRec.time" zum Speichern des Wertes?

Danach kannst Du Dir mit DateTimeToStr(FileDateToDateTime(GespeicherterInte ger)) das Datum anzeigen lassen.

[JanWe]

äh, mhh, jetzt ich bin langsam verwirrt :D
(naja, bin auch noch Programmieranfänger)

also ich möchte alle Dateien in einem Verzeichnis scannen und das korrekte Dateidatum ermitteln. Naja OK, die weitere Speicherung ist zweitrangig - und wie sich ja ergeben hat, als integer - auch weniger leicht.


a) Aber was ich nicht verstehe ist, warum Dateien mit dem Datum vor 1.1.1980 (gerade festgestellt ... Dateidatum VOR 1980 macht schon Probleme) von Delphi nicht mit searchrec.time ermittelt werden können?
stattdessen wird der time-Wert der vorherigen Datei unverändert gelassen (und an den Array weitergereicht, wie man in den Screenshots im Anfangspost lesen kann).

b) Auch das mit dem Findfirst versteh ich nicht. - ich dachte immer, der Befehl sucht nur das erste Vorkommen einer Datei (also z.B. Dateien mit 'rz****', oder '*.tmp') oder ähnliches.

Aber dennoch schon mal allen Danke für die bisherigen Antworten.

[himitsu]

Weil für dieses Datumsformat nunmal eine Grenze definiert ist und diese liegt halt bei 1980.
Grund, siehe "Zeit der letzten Änderung" und "Datum der letzten Änderung" in http://de.wikipedia.org/wiki/File_Allocation_Table

Aus jenem Grund haben etwas aktuellere Delphis da auch zusätzlich weitere/neuere Datums-Felder in dem Record.

In einen Integer passen nicht unbegrenzt Daten rein.
Beispiel: http://de.wikipedia.org/wiki/Unixzeit


Du kannst gern mit einem Fiat Punto deinen Umzug machen, aber da du nur einmal fahren darfst, muß alles gleichzeitig dort rein ... so viel, wie halt rein geht.


Ach ja, egal was man umwandelt, multimpiziert oder sonstwie berechnet ... man kann aus einem ungültigen Wert niemals einen Gültigen mehr machen.


mögliche Lösungen:

• System.SysUtils.TSearchRec.FindData
• FindFirstFile
• GetFileTime
• oder keine solchen alten Dateien verwenden

[Dalai]

Zitat:

Zitat von JanWe (Beitrag 1298236)

b) Auch das mit dem Findfirst versteh ich nicht. - ich dachte immer, der Befehl sucht nur das erste Vorkommen einer Datei (also z.B. Dateien mit 'rz****', oder '*.tmp') oder ähnliches.

Vorsicht: FindFirstFile <> FindFirst! Ich meinte erstere. Und natürlich muss man (in diesem Fall) FindFirstFile in Verbindung mit FindNextFile verwenden.

Aber himitsu hat recht, die Inhalte des TWin32FindData sind ja auch im TSearchRec.FindData zu finden, es ist also nicht unbedingt notwendig, FindFirstFile/FindNextFile statt FindFirst/FindNext zu benutzen.

MfG Dalai

[Perlsau]

Zitat:

Zitat von JanWe (Beitrag 1298236)

Aber was ich nicht verstehe ist, warum Dateien mit dem Datum vor 1.1.1980 (gerade festgestellt ... Dateidatum VOR 1980 macht schon Probleme) von Delphi nicht mit searchrec.time ermittelt werden können?

Damals gab es noch nicht einmal DOS, somit kann es auch keine Dateien mit diesem Datum geben. Z.B. den C64 gab es erst seit 1982, und theoretisch könntest du auf deinem PC auch Dateien haben, die von einem C64 stammen und mit einem entsprechenden Umwandlungsprogramm an das Dateisystem deines PC angepaßt wurden. Dieses Umwandlungsprogramm gab es aber erst, nachdem die ersten Diskettenlaufwerke für C64 erschienen waren. Was ich damit sagen will: Es ist mehr als unwahrscheinlich, daß du auf deinem PC Dateien hast, die vor 1980 erstellt worden sind. Natürlich könntest du das Erstellungsdatum einer Datei auch nachträglich manipulieren und z.B. auf 01.01.1979 zurücksetzen. Scheint mir aber nicht wirklich Sinn zu machen ...

[BadenPower]

Zitat:

Zitat von JanWe (Beitrag 1298236)

Naja OK, die weitere Speicherung ist zweitrangig - und wie sich ja ergeben hat, als integer - auch weniger leicht.

Ich glaube nicht, dass Du das verstanden hast.

Du hast doch schon einen Integer, wenn Du die Daten mit FindFirst oder FindNext ausliest.

In Deinem Code-Beispiel in Post #1 ist in "search.Time" das Datum als Integer-Wert und diesen speicherst Du einfach ab.

[Popov]

Zitat:

Zitat von JanWe (Beitrag 1298236)

äh, mhh, jetzt ich bin langsam verwirrt :D

Das brauchst du nicht, aber vielleicht weigerst du dich einfach nur paar Tatsachen zu akzeptieren. Eine wäre, es gibt keine Dateien die vor 1980 auf einem PC abgelegt sein können. Gut, ich dachte es war 1970, ist aber nicht so wichtig. Es ist irgendwas dazwischen. Der Grund ist, 1980 war der Speicher verdammt teuer, da verplempert man den nicht mit unwichtigen Daten, die es davor nicht gab, wie z. B. den Brief von Pontius Pilatus an das römische Senat, verfasst in Word 0.1 im Jahr... so um 30. Damals gab es keine Computer. Auch hat Luther seine Thesen nicht in Word 0.3 geschrieben. Auch da gab es keine Computer. Der PC wurde so um 1976/77 erfunden. Somit wurden davor keine Daten auf den PC abgelegt.

Wozu also Speicher für Daten bereithalten, die es vor 1970 nicht gab. Für das Jahr 1968 braucht man zusätzliche 7 Bits. Wofür. Also hat man getrickst und beschlossen, die Zeitrechnung auf Computern beginnt im Jahr 1970 (oder so ähnlich). Wenn also im Jahr 2015 eine Datei abgespeichert wird, wird nur das Jahr 45 gespeichert. Fragt man das System jetzt wann die Datei gespeichert wurde, nimmt es die 45 und addiert 1970 dazu. Ergebnis 2015. Ist ein Trick, man spart 7 Bits.

Deshalb kann es auch keine Datum-Daten vor vor 1970 geben, denn das System kann nicht kleinere Werte als 0 ablegen. Somit kann jede Datei ohne Datum nur mit 1970 anfangen.

Und nun kommst du mit deinem Delphi-Datum an. Auch Delphi muss tricksen, damit es ein Datum plus Uhrzeit in eine Double speichern kann. Ein Double kommt mit 8 Bytes aus. Das würde nicht für ein volles Datum reichen, aber Delphi ist großzügiger, es beginnt bei 1900.

Also, es gibt keine Daten von vor 1970, also findet sich auf dem System auch kein Datum von vor 1970. Das solltest du akzeptieren.

Zitat:

also ich möchte alle Dateien in einem Verzeichnis scannen und das korrekte Dateidatum ermitteln. Naja OK, die weitere Speicherung ist zweitrangig - und wie sich ja ergeben hat, als integer - auch weniger leicht.

Das ist superleicht. Nichts leichter als das Dateidatum zu speichern. Nur man kann dir hundert mal sagen wie du es machen sollst, du weigerst dich einfach. Du willst unbedingt dein Delphi-Datum speichern und das geht nicht mit einem Integer. Das Time-Datum der Datei ist aber schon ein Integer. Und was du dich seit Stunden weigerst zu machen ist einfach den Search.Time Wert zu speichern, statt das FileDateToDateTime. Wo ist das Problem die Funktion FileDateToDateTime zu entfernen und schon hat man das was man will. Aber nö, du willst unbedingt das FileDateToDateTime Datum speichern. Dann versuche es weiter.

Zitat:

a) Aber was ich nicht verstehe ist, warum Dateien mit dem Datum vor 1.1.1980 (gerade festgestellt ... Dateidatum VOR 1980 macht schon Probleme) von Delphi nicht mit searchrec.time ermittelt werden können?

Wie gesagt, den Grund wurde dir schon vor Stunden genannt. Du weigerst dich das einfach zu verstehen.

[JanWe]

ha!
jo, entschuldigt, wenn ich Euch auf die Nerven gegangen bin.

naja, für mich war das logisch die ins normale DateTime konvertierte FileDateTime zu speichern, weil ich dachte, mit dem DateTime würde man öfter rechnen, da ich beim Implementieren im web/google und in delphi foren viel über das Gemaule/Unverständnis beim Weiterverarbeiten vom unkonvertierten Dateidatum gestolpert war, und das bei mir vermeiden wollte ;D

nein, von daher hab ich die Integer nicht ingoriert. Ich hielt sie einfach nur nicht für ein "richtiges" Datum :D wegen FileTime<>Datum u. Zeit :D

Mhh, ja und die Dateien kommen bei mir schon vor.
Nicht von CDs oder gar überspielten 5¼" Disketten des "Brotkastens" (c64).
Ich hab nämlich mit dem SpeedCommander per normalem FTP von einigen Servern heruntergeladen und das Dateidatum mit übernommen ... und da haben die Server wohl Mist gesendet: Denn teilweise wurde dabei das Lastchange auf 1.1.1970 gesetzt.

Von daher is das für mich natürlich schon wichtig, da ich die alle katalogisieren wollte.

Also noch einmal herzlichen Dank an ALLE!

[Popov]

Wie schon gesagt, man kann das Search.Time speichern und FileDateToDateTime nutzen wenn man es benötigt.

Wenn es aber unbedingt sein muss, obwohl, ob ich nun mit FileDateToDateTime beizeiten das Datum passend konvertiere oder es vorher durch 100000 tiele, ist eigentlich gehopst wie gesprungen.

Aber wenn unbedingt sein muss, wenn du Datum und Uhrzeit trennst, also jede der Angaben separat speicherst, dann sollte das auch mit Integer gehen:

Delphi-Quellcode:

var
  Datum, Uhrzeit: Integer;
  DateTime: TDateTime;
begin
  Datum := Trunc(Now);
  Uhrzeit := Trunc((Now - Datum) * 100000);

  DateTime := Datum + (Uhrzeit / 100000);
  ShowMessage(DateTimeToStr(DateTime));
end;

Zitat:

Denn teilweise wurde dabei das Lastchange auf 1.1.1970 gesetzt.

Kommt schon vor, nur ältere Daten wirst du nicht bekommen. Wie gesagt, das ist das Jahr 0 bei Computern. Dieses Datum siehst du wenn im Speicher 0 steht. Was du siehst ist nur die bereinige Version.

[Bjoerk]

Jain. 0 ist nicht konvertierbar. Geht erst ab 2162688 (1.1.80). (Siehe auch himitsu)

Delphi-Quellcode:

  I := DateTimeToFileDate(StrToDateTime('1.1.1980'));
  ShowMessage(DateTimeToStr(FileDateToDateTime(I - 1))); // -> Exception

[BadenPower]

Zitat:

Zitat von Bjoerk (Beitrag 1298263)

Jain. 0 ist nicht konvertierbar. Geht erst ab 2162688 (1.1.80). (Siehe auch himitsu)

Um genau zu sein:

2162688 entspricht dem 01.01.1980 um 00:00:01 Uhr.

[Perlsau]

Gerade habe ich eine Textdatei erstellt und nachträglich Erstelldatum sowie Änderungdatum geändert. Seltsamerweise zeigt der FreeCommander das korrekte Änderungsdatum 17.04.1970 22:45 an, der Windows-Explorer zeigt dagegen gar kein Datum an. Auch ein Änderungsdatum 23.08.1804 01:15 wird nach Eingabe im FreeCommander korrekt angezeigt. Also irgendwie muß der FreeCommander das ja auch speichern und auslesen. Offenbar gibt es hier doch weitere Möglichkeiten, obwohl es ja laut Popov gar nicht möglich ein sollte, ein solches Datum überhaupt erst zu erzeugen bzw. einer Datei zuzuweisen.

[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:

Zitat von Perlsau (Beitrag 1298266)

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. :stupid:
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. :roll:

[Dalai]

Zitat:

Zitat von himitsu (Beitrag 1298287)

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

Aber gerne doch: Helpdesk :mrgreen:.

MfG Dalai

[Popov]

Zitat:

Zitat von himitsu (Beitrag 1298287)

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

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.