I´m retrieving file modification time using
type(FILE$INFO):: FileInfo integer(KIND=INT_PTR_KIND( ))Handle !... Handle=FILE$FIRST irc=GETFILEINFOQQ(trim(fname),FileInfo,Handle) if(irc.le.0)then ! ... endif call UNPACKTIMEQQ(FileInfo%lastwrite,iyr2,imon2,iday2,ihr2,imin2,isec2)
This yields a time of 19:44.
Windows explorer says it is 18:44.
GNU stat (on cygwin) says it is "2016-10-25 18:44:10.210373000 +0200"
My timezone is UTC+1, then we have daylight saving time, which sort of makes it UTC+2.
So it seems GetFileInfo/UnpackTimeQQ disregards DST - is this the expected behavior? Is there a fortran way to handle dst also? I´d like to avoid calling a C function, although I think I have a working solution there:
FILETIME modtime; LPFILETIME localModTime; SYSTEMTIME st; SYSTEMTIME stLocal; HANDLE fh; wchar_t path = _T("my.file"); wchar_t date, time; fh = CreateFileW(path, GENERIC_READ | FILE_WRITE_ATTRIBUTES, 0, NULL, OPEN_EXISTING, 0, NULL); GetFileTime(fh, NULL, NULL, &modtime); FileTimeToSystemTime(&modtime, &st); SystemTimeToTzSpecificLocalTime(NULL, &st, &stLocal); int ret; ret = GetDateFormatEx(LOCALE_NAME_USER_DEFAULT, DATE_LONGDATE, &stLocal, NULL, date, sizeof date / sizeof date, NULL); ret = GetTimeFormatEx(LOCALE_NAME_USER_DEFAULT, 0, &stLocal, NULL, time, sizeof time / sizeof time); wprintf(L"File last modified at %s at %s.\n", date, time);
Here's the weird thing - it happens only when you link to the DLL libraries. FINDFILEQQ is mainly a wrapper for C library routines _findfirst and _findnext. The DLL forms of these libraries appear to be returning times that don't account for DST. It isn't UNPACKTIMEQQ that is making the error.
This may turn out to be a Microsoft bug, but we'll poke at it some more. Escalated as issue DPD200415437.
Thanks, Steve. I´ll need to resolve this before Christmas, either by a workaround in our code or by applying some patch/update. Is there a way I can follow the status of this issue so that I can decide what to do?
The simple workaround is to link to the static libraries. Alternatively you can call the Windows API routines either from C, as you have it, or directly from Fortran. While GETFILEINFOQQ is convenient, it isn't really much harder to use the APIs and they don't seem to have this issue.
This thread will get updated with status, but even if we can make a fix for this (I am skeptical), it wouldn't be any earlier than February.
It turns out that this is a bug in the Microsoft Visual C++ 2010 libraries and not any other version. The way the Intel Fortran DLL library works is that it isn't linked to a specific MSVC DLL but instead tries a run-time load of various versions. If it ends up with the 2010 version then you'll see the error, but not later versions. If your system doesn't have the 2010 version, you won't see the problem.