TSearchRec Time on Windows / Linux problem

[cris75]

HI,
suppose we access the attributes of a TSearchRec, "Time" would be the time (and date) of the last modification, a longint that can be converted back to a human readable format via DateTimeToStr(FileDateTodateTime( TSearchRec.Time )), correct me if I'm wrong;
I wrote a small program that scans a directory (via FindFirst) and returns the "last modified time" of all files in it, what I noticed is that the values ​​stored in TSearchRec.Time are completely different when I run the program in Windows compared to when I run it on Linux.
From what I found searching online I'm pretty sure this is due to an "internal" time conversion mechanism in both operating systems, but this also means that if I run the program in Linux, I can't use the value contained in TSearchRec.Time and convert it again via the "FileDateTodateTime" function, this time in a Windows test program written specifically to check it (in fact I get conversion errors);
If I copy an existing (old) file from my Debian machine to my Windows 10 VM and then go and check the "last modified" property of that file in both operating systems (via Dophin/Explorer), as I expected they are identical, (same date and time reported), so I assume that the operating systems automatically manage these conversions;
Is there a function that can handle this "conversion"?
(I mean, in my case "get" the value of the TSearchRec.Time attribute in Linux and then somehow correctly convert it back to a human readable date and time in Windows - and vice versa)

[Thaddy]

Windows and linux have a different time pivot:
unix counts from /1/1/1970
windows counts from /12/31/1899 i

There are conversion functions, though, like datetimetounix
See the manual:
https://www.freepascal.org/docs-html/rtl/dateutils/datetimetounix.html.

[PascalDragon]

HI,
suppose we access the attributes of a TSearchRec, "Time" would be the time (and date) of the last modification, a longint that can be converted back to a human readable format via DateTimeToStr(FileDateTodateTime( TSearchRec.Time )), correct me if I'm wrong;
I wrote a small program that scans a directory (via FindFirst) and returns the "last modified time" of all files in it, what I noticed is that the values ​​stored in TSearchRec.Time are completely different when I run the program in Windows compared to when I run it on Linux.
From what I found searching online I'm pretty sure this is due to an "internal" time conversion mechanism in both operating systems, but this also means that if I run the program in Linux, I can't use the value contained in TSearchRec.Time and convert it again via the "FileDateTodateTime" function, this time in a Windows test program written specifically to check it (in fact I get conversion errors);
If I copy an existing (old) file from my Debian machine to my Windows 10 VM and then go and check the "last modified" property of that file in both operating systems (via Dophin/Explorer), as I expected they are identical, (same date and time reported), so I assume that the operating systems automatically manage these conversions;
Is there a function that can handle this "conversion"?
(I mean, in my case "get" the value of the TSearchRec.Time attribute in Linux and then somehow correctly convert it back to a human readable date and time in Windows - and vice versa)

Please provide concrete examples of what kind of differences you see.

Windows and linux have a different time pivot:
unix counts from /1/1/1970
windows counts from /12/31/1899 i

FileDateToDateTime is supposed to take care of that already.

[marcov]

There is also local time vs UTC, so a deviation of a few hours could be caused by that .

Btw FPC 3.2.4 will have

Code: Pascal  [Select][+][-]

1.     property TimeStamp: TDateTime read GetTimeStamp;
2.     property TimeStampUTC: TDateTime read GetTimeStampUTC;

in sysutils.searchrec.