views:

76

answers:

3

I'm having serious trouble with the function stat(). I have an application compiled under cygwin ond Windows 7 and the same app compiled with MSVC++ on Windows 7. The app contains the following code:

struct stat stb;
memset( &stb, 0, sizeof( stb ) );

stat( szPath, &stb );

cout << hex << uppercase << setw(8) << stb.st_mtime << endl;

szPath is a path to a file. The file does not get modified in any way by the app. The problem is, that i get different results for some files. For example:

cygwin version: 40216D72
MSVC++ version: 40217B82

The difference is always E10 = 3600 = 1 hour

By using google, i found this, which seems to be exactly the same issue i'm seeing. Is there a portable way how to fix this? I cannot use any WinAPI calls. The most simple and reliable solution is what i'm looking for, but if it needs to be complicated, so be it. Reliability and portability (win + linux) is the most important thing here.

A: 

Apparently per http://support.microsoft.com/kb/190315 this is actually a FEATURE although it really seems like a bug to me. They say you can work around it by clearing "Automatically adjust clock for daylight saving changes" in the Date/Time Properties dialog box for the system clock.

If you have the date of the file, you can use the relative state of dst to determine if you need to make a one-hour adjustment yourself in MSVC only, but that's hacky as well.

Mark B
A: 

Not sure about the functions you are using but I do know that Windows and Linux use the system clock differently. Windows stores local time (including DST) on the system clock. Linux (at least traditionally) stores GMT (or UTC to be precise) on the system clock. I don't if this applies to cygwin.

If a linux system shares hardware with windows it needs to be configured to use the system clock like windows or get messed-up every time windows adjusts DST.

+2  A: 

To obtain both reliability and portability here (or in most situations of this sort where two platforms do different things with what should be the "same" code), you will probably need to use some form of target-dependent code, like:

#ifdef _MSC_VER
   // do MSVC++-specific code
#else
   // do Linux/Cygwin/generic code
#endif

You then ought to be able to use WinAPI calls in the _MSC_VER section, because that will only be compiled when you're using MSVC++

Brooks Moses
Will try that, althought its not the kind of solution i like. It seems thought that there wont be any other option.
PeterK