Getting incorrect file modification time using stat APIs

Question

I see a strange behavior while fetching the modification time of a file. we have been calling _stat64 method to fetch the file modification in our project as following.

int my_win_stat( const char *path, struct _stati64 *buf)
{  
 if(_stati64( path, buf) == 0)
 {
   std::cout<<buf->st_mtime << std::endl; //I added to ensure if value is not changing elsewhere in the function.
 }
 ...........
 ...........
}

When I convert the epoch time returned by st_mtime variable using epoch convertor, it shows 2:30 hrs ahead of current time set on my system.

When I call same API as following from different test project, I see the correct mtime (i.e. according to mtime of file shown by my system).

if (_stat64("D:\\engine_cost.frm", &buffer) == 0)
    std::cout << buffer.st_mtime << std::endl;

Even I called GetFileTime() and converted FILETIME to epoch time with the help of this post. I get the correct time according to time set the system.

if (GetFileTime(hFile, &ftCreate, &ftAccess, &ftWrite))
{
    ULARGE_INTEGER ull;
    ull.LowPart = ftWrite.dwLowDateTime;
    ull.HighPart = ftWrite.dwHighDateTime;

    std::cout << (ull.QuadPart / 10000000ULL - 11644473600ULL);
}

What I am not able to figure out is why does the time mtime differ when called through my existing project?
What are the parameters that could affect the output of mtime ?
What else I could try to debug the problem further ?

Note

1. In VS2013, _stati64 is a macro which is replaced replaced by _stat64.
2. File system is NTFS on windows 7.

Answer 1

Unix time is really easy to deal with. It's the number of seconds since Jan 1, 1970 (i.e. 0 represents that specific date).

Now, what you are saying is that you are testing your time (mtime) with a 3rd party tool in your browser and expects that to give you the right answer. So... let's do a test, the following number is Sept 1, 2015 at 00:00:00 GMT.

1441065600

If you go to Epoch Converter and use that very value, does it give you the correct GMT? (if not, something is really wrong.) Then look at the local time value and see whether you get what you would expect for GMT midnight. (Note that I use GMT since Epoch Converter uses that abbreviation, but the correct abbreviation is UTC.)

It seems to me that it is very likely that your code extracts the correct time, but the epoch convertor fails on your computer for local time.

Note that you could just test in your C++ program with something like this:

std::cerr << ctime(&buf->st_mtime) << std::endl;

(just watch out as ctime() is not thread safe)

That will give you the data according to your locale on your computer at runtime.

To better control the date format, use strftime(). That function makes use of a tm structure so you have to first call gmtime or localtime.

Answer 2

An year later I ran into the similar problem but scenario is little different. But this time I understand why there was a +2:30Hrs of gap. I execute the C++ program through a perl script which intern sets the timezone 'GMT-3' and my machine had been in timezone 'GMT+5:30'. As a result there was a difference of '2:30Hrs'. Why ? As Harry mentioned in this post

changing the timezone in Perl is probably causing the TZ environment variable to be set, which affects the C runtime library as per the documentation for _tzset.