First, I convert it to a Windows filesystem time - which is similar to the Javatime, except from the start time offset and the time resolution. Next, I convert the filetime to Windows UTC time, and adjust for the timezone - simplified to just use the default - ie current local timezone. The final step is to convert the system time constant to a TDateTime.
The whole thing is done with blatant disregard of the tradition of checking return values from the two system calls. The less optimistic of you may choose to check for return values equaling zero to indicate an error.
FYI: 11644473600000 * 10000 = 1 Jan 1970 in Windows File Time
uses
Windows, SysUtils; // Time functions
function JavaTimeToDateTime(javatime:Int64):TDateTime;
// java time -> Win32 file time -> UTC time
// adjust to active time zone -> TDateTime
var
UTCTime, LocalTime: TSystemTime;
begin
FileTimeToSystemTime(TFileTime(Int64(javatime + 11644473600000) * 10000), UTCTime);
SystemTimeToTzSpecificLocalTime(nil, UTCTime, LocalTime);
Result := SystemTimeToDateTime(LocalTime);
end;
FYI: SystemTimeToTzSpecificLocalTime function cannot be used to convert historical datetime in common case in XP and 2000 (I am not sure about Vista). Microsoft guys say only current datatime converted correctly and even those ones not always (it depends on some windows updates). We had a big trouble there and wrote special convertion function that uses real historical data :).
ReplyDeleteAlec.
Thanks, Alec! Useful info! I assume the Daylight Saving Time factor can be tricky as the dates have changed over the years.
ReplyDeleteI guess a more reliable approach would be to calculate and add the time offset yourself. For my use, the the dates don't go very far back and the software runs in a controlled environment (with regards to Windows updates/patches) - so it is less of a problem for me.