Bug in CTIME?

[grtoro]

I have the following function(originally written for HP-UX FORTRAN) that returns the creation date of a file

      CHARACTER*44 FUNCTION FILE_TIME(FILE) 
C 
C     Machine-specific subroutine to return creation date of a file 
C     HP version 
C 
      CHARACTER*(*) FILE 
      CHARACTER*24 TIME 
C 
      INTEGER IFILE_INFO(12) 
      CHARACTER*24 Ctime 
C     ----------------------
C     see "man 3f stat" 
      CALL STAT(FILE,IFILE_INFO) 
c     see "man 3f ctime"
      TIME=Ctime(  IFILE_INFO(10) ) 
C 
      FILE_TIME='File Creation Date: '//TIME 
      RETURN 
      END 

(Sorry if the code is wrapping; I don't remember the trick to avoid wrapping)

After re-compiling some programs that use this function (previously compiled with an earlier version of CVF [not sure of 5.0 or 6.1]), I noticed that the creation dates of some files from 1998 now appear as one hour earlier. The time calculated wih CVF 6.6A is inconsistent with the time displayed by the OS.

Is this a known bug? Is it CVFs or in W98s fault? Fortunately, this is not a serious bug. Am I doing anything wrong?

Thanks,

Gabriel

[james1]

This reproduces on XP. Actually I think CTIME is fine but the problem is with STAT. CTIME is just printing what STAT has provided to it. The time returned is off by an hour during daylight savings time from STAT.

James

[Steven_L_Intel1]

Please report this to vf-support@compaq.com and our library expert will look at it.

Steve

[james1]

Gabriel,

When you submit your report mention that GETFILEINFOQQ has the same issue.

James

[Steven_L_Intel1]

Um, GETFILEINFOQQ just passes on the data it gets from FindFirstFile.

Steve

[james1]

Er, you cannot just be returning whatever FindFirstFile gives you as it is expressed in different units, so perhaps the problem is in the conversion. I just wrote a quick test to return the last write time, both from GETFILEINFOQQ and FindFirstFile. If the time in question is not during DST then they indeed agree. If the time in question is during DST they differ by exactly 3600 as I stated previously.

James

[Intel_C_Intel]

I too have had troubles with what is GMT & BST in the UK. I found that the result of using CTIME depended not upon whether the time to be converted was in the GMT or BST times of year, but whether the computer reckoned it was in GMT or BST. Changing the computer Date/Time from a date in one to a date in the other causes a one-hour shift in the conversion result.

[grtoro]

It gets curioser and curioser...

Others in this thread have been able to reproduce the problem, but the people at vf-support cannot reproduce it. One possible complicating factor is that I have set environment variable TZ to EST5EDT (TZ is required by the Win32 version of rcs). AFAIK, this TZ setting is equivalent to the W98 time setting (US Eastern time, adjust for daylight savings time). I am not sure how, and if, TZ interacts with FILE_INFO and CTIME.

Gabriel

[james1]

I don't have TZ set but certainly see the problem. Keeping in mind of course, that CTIME itself works properly, but STAT and GETFILEINFOQQ are feeding it a time that is off by 3600 seconds in the circumstances described. Did you report this as a problem with CTIME or with the latter routines?

James

[james1]

Also I suspect anyone having this problem has Control Panel -> Date and Time -> Time Zone -> Automatically adjust clock for daylight saving changes selected. That might help support better understand the issue.

James

[Steven_L_Intel1]

I tried this on two different systems, one Windows 2000, one Windows XP. Both have the 'automatically adjust for daylight savings time' option set, however we are currently in standard time. On both systems, the program returned the correct time.

Steve

[james1]

Steve,

Here is a quick program with run results on my system. In particular note the difference in numeric values returned in the case where the file is within DST and we currently aren't.

 
Microsoft Windows XP [Version 5.1.2600] 
(C) Copyright 1985-2001 Microsoft Corp. 
 
E:>type ctm.f90 
program ctime_works 
use kernel32 
character(*), parameter :: filename = 'ctime_works.tmp' 
character(24) ctime 
integer(4) stat 
type (T_SYSTEMTIME) dst_systime, nodst_systime 
type (T_FILETIME) dst_filtime, nodst_filtime 
integer(DWORDLONG) base /116444736000000000/, dst, nodst 
equivalence (dst, dst_filtime), (nodst, nodst_filtime) 
integer(HANDLE) hFile 
integer(4) values(12), dst_time, nodst_time 
 
dst_systime = T_SYSTEMTIME (1970, 6, 0, 1, 0, 0, 0, 0) 
nodst_systime = T_SYSTEMTIME (1970, 11, 0, 1, 0, 0, 0, 0) 
 
call SystemTimeToFileTime (dst_systime, dst_filtime) 
call SystemTimeToFileTime (nodst_systime, nodst_filtime) 
dst_time = FLOAT (dst - base) / 1.E7 
nodst_time = FLOAT (nodst - base) / 1.E7 
 
hFile = CreateFile(filename//CHAR(0), GENERIC_WRITE, 0, & 
  null_security_attributes, CREATE_ALWAYS, 0, NULL) 
 
call SetFileTime(hFile,NULL,NULL,nodst_filtime) 
call STAT (filename, values) 
type '(x,a,i0,a,i0)', 'STAT returns ', values(10), ' expected ', nodst_time 
type *, 'Formatted ', CTIME(values(10)), ' expected ', CTIME(nodst_time) 
 
call SetFileTime(hFile,NULL,NULL,dst_filtime) 
call STAT (filename, values) 
type '(x,a,i0,a,i0)', 'STAT returns ', values(10), ' expected ', dst_time 
type *, 'Formatted ', CTIME(values(10)), ' expected ', CTIME(dst_time) 
 
call CloseHandle (hFile) 
 
end 
E:>df ctime_works 
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update A) 
Copyright 2001 Compaq Computer Corp. All rights reserved. 
 
ctm 
Microsoft  Incremental Linker Version 6.00.8447 
Copyright (C) Microsoft Corp 1992-1998. All rights reserved. 
 
/subsystem:console 
/entry:mainCRTStartup 
/ignore:505 
/debugtype:cv 
/debug:minimal 
/pdb:none 
C:DOCUME~1JamesLOCALS~1Tempobj4B44.tmp 
dfor.lib 
libc.lib 
dfconsol.lib 
dfport.lib 
kernel32.lib 
/out:ctime_works.exe 
 
E:james3>ctime_works 
 STAT returns 26265600 expected 26265600 
 Formatted Sat Oct 31 16:00:00 1970 expected Sat Oct 31 16:00:00 1970 
 STAT returns 13042800 expected 13046400 
 Formatted Sun May 31 15:00:00 1970 expected Sun May 31 16:00:00 1970 

---

Hope this helps. :-)

James

[Steven_L_Intel1]

Oh, now I get it! You have to ask for the time of a file that was created when DST was in effect and it isn't currently (or perhaps vice-versa). That wasn't obvious from the original problem statement. I can reproduce this and will let Bill C know.

Steve

[Intel_C_Intel]

Um, I don't think we're quite at the bottom of this one yet - as I said earlier, change the date on the PC from (for us) GMT to BST and you get a different answer. Thanks to James Wilkinson for a program that worked first time on my PC. So I ran it - we're now in BST, then set the PC date back a month to when it was GMTwith the following results:

 
Result with PC date set to 5 April 2002.  Local time is BST.  
 STAT returns 26269200 expected 26265600   
 Formatted Sun Nov  1 02:00:00 1970 expected Sun Nov  1 01:00:00 1970   
 STAT returns 13046400 expected 13046400   
 Formatted Mon Jun  1 01:00:00 1970 expected Mon Jun  1 01:00:00 1970   
 
Result with PC date set to 5 March 2002.  Local Time is GMT.  
 STAT returns 26265600 expected 26265600   
 Formatted Sun Nov  1 00:00:00 1970 expected Sun Nov  1 00:00:00 1970   
 STAT returns 13042800 expected 13046400   
 Formatted Sun May 31 23:00:00 1970 expected Mon Jun  1 00:00:00 1970   

Because the results vary by 2 hours, I deduce that there are two bugs out there, not necessarily in the same routine, which is why bears get confused.

[james1]

Still one bug, STAT (and GETFILEINFOQQ I assume) add an hour when in DST for a time not in DST, and subtract an hour when not in DST for a time in DST. Your other hour is accounted for by using a different timezone that has an hour offset. Hey, I dream about living in GMT. :-)

James

[Intel_C_Intel]

James,

Posibly a part of your dream can come true. Part of the trouble with the whole subject is the fact that Event Viewer treats a change to Summer Time as a change in Time Zone. A fix may be found in Microsoft Q173054 - briefly, set your Time Zone to GMT, Uncheck the "Automatically adjust clock for daylight saving changes" box, and adjust time to local time.

When I do that on my works PC (HP) or home (Dell), your program then returns the expected answers, and because here in Wales we are naturally in the GMT zone, I will accept having to change the local time manually twice a year. So perhaps a summary might be:

 
Recent researches on Time Zones 
By Bear - one brain cell is all, 
Have conclusively proved that COMPAQ 
Is not the real culprit at all; 
And further exhaustive enquiries 
Have incontrovertably shown 
That the villain, as usual, was Microsoft: 
Well, shouldn't we really have known? 

End of story? - well, not quite. When I sent an executable of your program to a colleague, it ran giving the expected answers on his IBM portable, but he had still got the "Automatically adjust clock" box checked. Q139542 discusses the edjustments that some BIOS make. See also Q129574 and Q188891. Oh, and to finish me off, all my results had been from running from inside Dev Studio. When I clicked on the executable instead, it gave the current date/time instead of the 1970s date/times. It would seem that SetFileTime did not work. It's time I changed the subject.

[james1]

Yeah it doesn't help that Microsoft has their own problems in this area. They chose to use GMT to timestamp everything (great idea) but unfortunately do not follow through by implementing a DST table to properly convert to local time. The result is if you do a "dir" you'll see that whatever time bias is in effect at the time is applied to obtain the local time, even if that particular GMT time should have a different bias. Anyhow that is basically what they are talking about.

All that aside, CVF still needs to return the proper "GMT" times with these routines. Now, the next time we circulate a petition to rid the world of daylight savings time, I assume you will be signing! Heck, I'd even be willing to go to GMT and "spring forward" 8 hours if we only have to do it once and for all. :-)

James