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?

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?

Here''s the issue:

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

This is the problem.

I''ve read a lot about this, one particular link here: http://www.codeproject.com/datetime/dstbugs.asp?print=true

So, according to the above it sounds like I check the file''s date and based on that date (not the current date) decide if DST is in effect then use mktime to convert it? HELP!!! I am confused.

Their library is not much help either as I am not quite sure how to get it back into a FILETIME structure which I definately need.

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?

UPDATE:

The newest issue seems to be with FAT32 File Systems. I have a check so that if it is NTFS it uses the FILETIME retrieved. That is already in UTC Time.

The problem is on FAT32 Systems it is stored as the local time, there for it has to be converted to UTC time and also take into accounts Daylight Savings.

That is where I seem to be stuck. I can''t quite get it to work right.

Wouldn''t it be better to check the file version? instead of the time? You could create an install list of current major and minor version then update them if its less than the expected ............

Wouldn''t that mean that every time I make a slight update to a graphic I have to use some sort of program to update it''s version number?

In a game with hundreds of files, and every update containing mass numbers of files it''s easier to be able to copy all the new files over to the "updates" folder and let the program do the rest.

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.

I would rather just get it fixed now rather then trying to re-write a majority of it to implement something new, although I do like this idea to decrease download times on patches.

I''ll look into it further, but i''d still just like to fix the current problem before making it worse.