This is correct (though it won't end on 2034, it will overflow, thus resulting in a negative timestamp). You can use FileDateToDateTime to convert the Time field to a TDateTime (though with the same resolution restriction) or you can use the Timestamp property that's going to be introduced with 3.2 and which can - if available - use a higher resolution timestamp. E.g. on Windows it will use the modification time of type FILETIME in FindData while on *nix it currently uses the 32-bit timestamp, though that can be changed in the future.