problem with totime@ on 64bit compiler

I think that totime@ is not working correctly for 64bit ftn95. This is illustarted by the program

  program timetest
  character*8 totime@
  integer(kind=2) mode,dev,rdev,nlink,error_code
  integer(kind=3) size,atime,mtime,ctime
  call fileinfo@('data.txt',mode,dev,rdev,nlink,size,atime,mtime, &
                 ctime,error_code)
  write(*,\'(' atime,mtime,ctime ',3i11)\') atime,mtime,ctime
  write(*,\'(' totime@(ctime) ',a)\') totime@(ctime)
  stop
  end

The information on file data.txt from a directory listing: 26/07/2023 11:20 5 data.txt

Running the 64bit executable: atime,mtime,ctime 1690366828 1690366828 1690366824 totime@(ctime) 15:13:40

Running the 32bit executable: atime,mtime,ctime 1690366828 1690366828 1690366824 totime@(ctime) 10:20:24

ctime, returned from fileinfo@ is the same for both executables. We are currently on British summer time. In the Win32 executable, totime@ converts this to GMT. In the Win64 executable totime@ seems incorrect.

Have I done something silly?

Is there a way, from within an ftn95 program (by accessing an environment variable?) to detect whether we are currently on daylight savings or not?

In its 64bit version, TOTIME@ seems to count 64 seconds for a minute and 64 minutes for an hour, see below.

program timetest
character*8 totime@
write(*,900) 0,totime@(0)
write(*,900) 1,totime@(1)
write(*,900) 4095,totime@(4095)
write(*,900) 4096,totime@(4096)
900 FORMAT('totime@(',i4,') = ',a)
end

Output 32bit:totime@( 0) = 00:00:00 totime@( 1) = 00:00:01 totime@(4095) = 01:08:15 totime@(4096) = 01:08:16

Output 64bit:totime@( 0) = 19:47:31 totime@( 1) = 00:00:01 totime@(4095) = 00:63:63 totime@(4096) = 01:00:00

N.B.: The output TOTIME@(0) in its 64bit version varies with each call.

Thank you for the bug report.

These programs work correctly for me which means that a recent change to how we build clearwin64.dll has inadvertently fixed this issue.

The change to the build is not trivial and has not been 'road tested' so I will upload an alternative clearwin64.dll for users to try.

See http://forums.silverfrost.com/viewtopic.php?p=29221#29221.

Using the alternative ClearWin64.dll, the 64bit version of TOTIME@ gives one hour too much: totime@( 0) = 12:22:46 totime@( 1) = 01:00:01 totime@(4095) = 02:08:15 totime@(4096) = 02:08:16 On my computer, TOTIME@(0) seems to be system time + 2 hours, isn't that funny?

I assume that that relates to the time zone settings on your machine.

Do I understand correctly that TOTIME@ takes care of the time zone settings in the 64bit version but not in the 32bit version? Does TOTIME@(0) have a specific meaning in the 64bit version?

For me the results are not sensible for Win32. For x64 the result of totime@(0) is one hour ahead my time (BST) and two hours ahead of GMT.

I will make a note to investigate further.

TOTIME@ uses the tm structure from the C language and the member tm_sec for the number of seconds is in the range 0 to 60 (not 0 to 59) because it allows for the leap second. Further investigation will probably show that the results for Win32 (32 bits) are correct.

Apart from totime@(0) the results on my machine are consistent between 32 bits and 64 bits and I expect this to be true for the next full release.

totime(0) does currently have a particular meaning for 64 bits but this is probably not helpful so it will be changed to make it consistent with 32 bits.

The following program illustrates how TOTIME@ and TODATE@ can be called and provides a test for consistency between results for 32 bits and those for 64 bits.

1. TOTIME@ has been fixed so that the 64 bits results will be compatible in a future release.

2. Both of these subroutines pass a 32 bit integer value which means that they will not work after 19 January 2038 (only 15 years!).

   program test character8 totime@,todate@ real8 dr integer*4 msecs,secs70,secs80

   msecs = huge(1) call seconds_since_1970@(dr) secs70 = int(dr) call seconds_since_1980@(dr) secs80 = int(dr)

   print*, 'Largest integer4 =', msecs print, 'Last date = ', todate@(msecs) print*, 'Today's date = ', todate@(secs70) print*, 'Today's date = ', todate@(secs80) print*, 'Today's time = ', totime@(secs70) print*, 'Today's time = ', totime@(secs80)

   end program

A caveat to my last post is required...

I have now tested patrickm's original program (testtime) using the reported fix to TOTIME@ and the results for the file created time are now consistent between 32 and 64 bits except for a daylight saving hour.

In this respect the results for 64 bits are consistent with the creation time in the Properties dialog of File Manager but there can be a one-hour difference for 32 bits (when the file is created in UK summer, say, and the program is run in winter).

Hopefully the 64 bit result is better in this respect.

Regarding the expiry date, if anyone using these routines is planning ahead for more than 15 years then we can provide 64 bit versions that pass 64 bit rather than 32 bit integers.