Aber warum funktioniert FileTimeToDateTime dann unter Linux, wenn als Parameter ein LongInt verwendet wird (mein og. Beispiel mit Searchrec.time)
Weil das Searchrec unter Linux das Datum und die Uhrzeit natürlich schon korrekt codiert enthält. Das kommt ja vom Betriebssystem und nicht aus der ZIP-Datei.
Wobei das "Zipfile.FileInfo[c].ModifiedDateTime" auf allen Plattformen denselben Wert enthält.
FileDateToDateTime, das als Parameter ein LongInt erwartet - macht daher unter Windows den richtigen Wert draus, da UINT32 auch unter Windows ein 4 Byte Wert ist, wie eben auch LongInt.
Unter Linux 64 Bit ist LongInt aber ein 8 Byte Wert, daher kann man letztlich nicht den UINT32-4-Byte Wert an eine Funktion übergeben, die unter Linux (anders als unter Windows) einen 8 Byte-Wert erwartet.
"searchrec.Time" ist unter Windows ein Integer (ist unter Windows übrigens als "platform deprecated" gekennzeichnet), unter posix als time_t platform und als LongInt deklariert. Da Integer und LongInt unter Windows beides mal 4 Byte haben, macht es nichts, dass der Paramenter von FileTimeToDateTime "LongInt" ist. Aber unter Linux-64 ist LongInt eben 8 Byte. Searchrec hat es mit der oben beschriebenen Weise dann für Linux angepasst, so dass die Werte für "time" stimmen. UINT32 bleibt aber immer 4 Byte.
Die Werte in Zipfile.FileInfo[c].ModifiedDateTime sind daher auch nicht falsch, sondern müssen eben je nach Plattform nur anders ausgewertet werden. Aber da muss man erst mal drauf kommen...
Ich habe daher auch mal den Titel des Threads geändert in "...richtig auslesen", damit man hier nicht einen falschen Eindruck bekommt.