Archived

This topic is now archived and is closed to further replies.

IronDragon

FILETIME Problem

Recommended Posts

IronDragon    122
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?

Share this post


Link to post
Share on other sites
CWizard    127
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
IronDragon    122
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.

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.

ULARGEINTEGER myfiletimecopiedtoULARGE_INTERGER;

myfiletimecopiedtoULARGE_INTEGER.LowPart = myfiletime.dwLowDateTime;
myfiletimecopiedtoULARGE_INTEGER.HighPart = myfiletime.dwHighDateTime;

myfiletimecopiedtoULARGE_INTEGER.QuadPart -= 3600000000000i64;

Share this post


Link to post
Share on other sites
IronDragon    122
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
IronDragon    122
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.

Share this post


Link to post
Share on other sites
afterburn    124
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 ............

Share this post


Link to post
Share on other sites
IronDragon    122
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.

Share this post


Link to post
Share on other sites
CWizard    127
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.


Share this post


Link to post
Share on other sites
IronDragon    122
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.

Share this post


Link to post
Share on other sites