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.
Das hat nichts mit 4 oder 8 Byte zu tun. Das MS-DOS FileDate, das bei Zip verwendet wird, ist ein 32Bit Wert mit folgendem Inhalt:
Code:
Bits
0- 4 Sekunden div 2
5-10 Minuten (0–59)
11-15 Stunden (0–23)
16-20 Tag (1–31)
21-24 Monat (1 = Januar, 2 = Februar, ...)
25-31 Jahr - 1980
Bei Unix ist es entweder ein 32- oder 64-Bit Wert, aber in jedem Fall stehen da die Anzahl der Sekunden seit dem (oder bis zum wenn negativ) 1. Januar 1970, 00:00 Uhr. Solange diese Anzahl in 32-Bit dargestellt werden kann, spielt es keine Rolle ob es ein 32-Bit oder 64-Bit System ist. Es ist immer eine Anzahl von Sekunden. Beim MS-DOS (und somit auch Zip-)Format ist das aber völlig anders.
Die Werte in Zipfile.FileInfo[c].ModifiedDateTime sind daher auch nicht falsch, sondern müssen eben je nach Plattform nur anders ausgewertet werden.
Eben nicht! Sie müssen auf allen Plattformen gleich ausgewertet werden. Deswegen geht
FileDateToDateTime auch nicht, da dieses die Auswertung je nach Plattform unterschiedlich macht (siehe das IFDEF).
1. Ich habe den Eindruck wir meinen wohl ziemlich ähnliches, reden aber ein wenig aneinander vorbei. Klar, ein 32-Bitiger Wert kann in 64-Bit enthalten sein und insofern auch ausgewertet werden. Manchmal gibt es aber Fälle, wo der ganze 64-Bit Wert, z.B. für eine Berechnung verwendet wird und wenn der nicht genullt ist (weil z.B. ein Zeiger auf einen Speicherbereich), dann kann es in einer solchen Konstellation zu Problemen führen (der Fall ist hier aber wohl nicht relevant).
2. Mit "anders auswerten" meinte ich ja auch, dass FileDateToDateTime nicht (auf allen Plattformen) verwendet werden kann...