|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
patrickm
Joined: 21 Jul 2023 Posts: 3
|
Posted: Wed Jul 26, 2023 12:25 pm Post subject: 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? |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 75
|
Posted: Wed Jul 26, 2023 2:45 pm Post subject: |
|
|
In its 64bit version, TOTIME@ seems to count 64 seconds for a minute and 64 minutes for an hour, see below.
Code: |
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8062 Location: Salford, UK
|
Posted: Tue Aug 01, 2023 7:43 am Post subject: |
|
|
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. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 75
|
Posted: Tue Aug 01, 2023 9:34 am Post subject: |
|
|
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? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8062 Location: Salford, UK
|
Posted: Tue Aug 01, 2023 10:20 am Post subject: |
|
|
I assume that that relates to the time zone settings on your machine. |
|
Back to top |
|
|
jlb
Joined: 21 Oct 2020 Posts: 75
|
Posted: Tue Aug 01, 2023 10:34 am Post subject: |
|
|
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? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8062 Location: Salford, UK
|
Posted: Tue Aug 01, 2023 11:39 am Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8062 Location: Salford, UK
|
Posted: Tue Oct 31, 2023 5:40 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8062 Location: Salford, UK
|
Posted: Wed Nov 01, 2023 10:16 am Post subject: |
|
|
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!).
Code: | program test
character*8 totime@,todate@
real*8 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 integer*4 =", 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
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8062 Location: Salford, UK
|
Posted: Wed Nov 01, 2023 11:34 am Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|