{SOLVED} Another problem with Daylight Savings Time

[jmm72]

I collect certain data from file contents and save it in another file. When reloading the file, I also try to match file name, date (modification date) and size) to link again that data with an existing file, otherwise I recalculate the data. Today I was refreshing this lil database and I had no matches although 98% of the data should have matched with existing files (just some file modifications and renames).

Further inspection showed me that the file date was not the one I was expecting. I collected the date before the DST change, but when reading the modification date from the file info (using FindFirstUTF8/FindNextUTF8) the date was different. I am not converting the date: the file record has a Time field as longint, and I store that longint which I compare again.

I suppose the system is adjusting the date of the files somehow, but I don't know how, and I don't understand why anyway. How should I get a fixed modification time+date from an existing file so these adjustements don't happen? And if anyone has any insight of why the system date of a file would change with DST, I'd be happy to hear too. TIA.

Edit:
Well, I found that the TSearchRec used in FileAge and FindFirst/FindNext also has the three NTFS dates as a FILETIME field inside FindData:

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

1. TSearchRec.FindData.ftCreationTime
2. TSearchRec.FindData.ftLastAccessTime
3. TSearchRec.FindData.ftLastWriteTime

The breakthrough for me, in this particular context, is that these dates are untouched, not modified from the NTFS data, so they are described as UTC dates without any timezone or DST correction.

So if I have a pointer to an int64 (it's a record with two DWORD/longword fields), I just do:

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

1. var
2.   a: TSearchRec;
3.   p: ^int64;
4.  
5. begin
6.   ...
7.   p := @a.FindData.ftLastWriteTime;
8.   DoWhateverWithFileTime(p^);
9. end;
10.  

I don't actually need to convert it to TDateTime or anything, but there are functions for that, like FileTimeToSystemTime, where the timezone and DST corrections take place. I think they are in the Windows unit, correct me if I'm wrong.

When/if I make my program multiplatform, I'll have to check how Unix saves the last modified time, and then to make them compatible I guess I'll have to transform each one into TDateTime and store in a neutral way, but without using the system functions which introduce this unwanted DST offset. I don't even know if Unix transforms an absolute UTC time into local time

I hope this is useful for someone.