Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1 View

File modifcation time with daylight saving time

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
Highlighted
Beginner
1 View

Just checked the behavior

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

0 Kudos
Highlighted
1 View

I can reproduce this and will

I can reproduce this and will investigate.

Retired 12/31/2016
0 Kudos
Highlighted
1 View

Here's the weird thing - it

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.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

Thanks, Steve. I´ll need to

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
Highlighted
1 View

The simple workaround is to

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.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

Linking statically would have

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

Thanks!
Uwe

0 Kudos
Highlighted
1 View

It turns out that this is a

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.

Retired 12/31/2016
0 Kudos