Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

File modifcation time with daylight saving time

Uwe_H_
Beginner
555 Views

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[256] = _T("my.file");
  wchar_t date[80], time[80];
  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[0], NULL);
  ret = GetTimeFormatEx(LOCALE_NAME_USER_DEFAULT, 0, &stLocal, NULL, time, sizeof time / sizeof time[0]);
  wprintf(L"File last modified at %s at %s.\n", date, time);

Thanks!

0 Kudos
7 Replies
Uwe_H_
Beginner
555 Views

Just checked the behavior with compiler version 15 - it reports the same modification time as win explorer (18:44 in this case)!

0 Kudos
Steven_L_Intel1
Employee
555 Views

I can reproduce this and will investigate.

0 Kudos
Steven_L_Intel1
Employee
555 Views

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.

0 Kudos
Uwe_H_
Beginner
555 Views

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?

0 Kudos
Steven_L_Intel1
Employee
555 Views

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.

0 Kudos
Uwe_H_
Beginner
555 Views

Linking statically would have affected to many projects, so I ended up doing a little C function.

Thanks!
Uwe

0 Kudos
Steven_L_Intel1
Employee
555 Views

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.

0 Kudos
Reply