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).