Recommended Posts

Ok. I had a semi long post here, but I may have a solution. All I need to know is if I have a FILETIME structure and I convert it to a UTC/GMT time using LocalFileTimeToFileTime this takes into account Daylight Savings -- how do I decrease 1 hour from it if Daylight Savings is in effect?

0

Share this post

Link to post

Share on other sites

I''m pretty sure it takes DLS into account. One way to perform calculations, convert it to a SYSTEMTIME and in this case substract from its day member, and then convert back to FILETIME. Isn''t there any time manipulation functions in Win32''s API?

Share this post

Link to post

Share on other sites

I have a patch program that downloads updated files. There for I get a Modified FILETIME from the Patch Server. I convert this to a UTC/GMT Time using LocalFileTimeToFileTime()

The same happens with the client, get it, covert it to a UTC/GMT time. Then the client compares the 2 files and updates as needed.

That seems right? Wrong! The LocalFileTimeToFileTime function can be off by 1 due to daylight savings. If the system is currently in daylight savings, then it will add 1 hour to the time. There for if I have a file, let''s say created on Jan 1, 4:04:03. Now daylight savings kicks into effect on the user''s system and it now thinks the file was created at 5:04:03

Share this post

Link to post

Share on other sites

Guest Anonymous Poster

Guest Anonymous Poster

You can tell whether or not you are in daylight savings time or not by utilizing the GetTimeZoneInformation function. Here''s a link to a MSDN page about it. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettimezoneinformation.asp

To actually modify the value of a filetime structure you should convert it into ULARGE_INTEGER structure and then simply perform arithmetic on it. This is the recommended way as it makes it so that you don''t have to deal with cases where the hours part of a system time is 0 already and such. FILETIME structures are based on 100 nanosecond increments so for a decrease one hour you should subtract 60 * 60 * 10,000,000,000 or 3600000000000. Since 3600000000000 is too large a number to fit into 32 bits you also have to specify that it is a 64bit constant by appending i64 to it so an example of use would be.

Share this post

Link to post

Share on other sites

Thanks. That worked for time conversions, now I am back to an older problem -- time zones. I keep ending up with several hours off when I change time zones, thus updating every file.

I believe it''s to do with the FileTimeToLocalFileTime and LocalFileTimeToFileTime functions. How would you go about this so that time zones are not effected. It works great if everyone was EST/EDT... but not everyone is perfect like us EST/EDT.

I think I am getting them confused as to how they are supposed to work -- or I am using them the opposite that I should be?

Share this post

Link to post

Share on other sites

I would agree version number would be better, at leasy for program files, but you may be right that it is too time consuming.

I think I understand what you''re doing, so I''ll propose another method. Let both the server and client keep a list of it''s files with cached CRC-32 checksum and file size information. Then the client sends his list to the server which compares it to its own. The server can then determine if there are any new or updated files and send them to the client. You may also consider using a rsync algorithm (more) in order to reduce bandwidth.