soccer jersey forums.silverfrost.com :: View topic - problem with totime@ on 64bit compiler
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

problem with totime@ on 64bit compiler

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
patrickm



Joined: 21 Jul 2023
Posts: 3

PostPosted: Wed Jul 26, 2023 12:25 pm    Post subject: problem with totime@ on 64bit compiler Reply with quote

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
View user's profile Send private message
jlb



Joined: 21 Oct 2020
Posts: 67

PostPosted: Wed Jul 26, 2023 2:45 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Tue Aug 01, 2023 7:43 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
jlb



Joined: 21 Oct 2020
Posts: 67

PostPosted: Tue Aug 01, 2023 9:34 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Tue Aug 01, 2023 10:20 am    Post subject: Reply with quote

I assume that that relates to the time zone settings on your machine.
Back to top
View user's profile Send private message AIM Address
jlb



Joined: 21 Oct 2020
Posts: 67

PostPosted: Tue Aug 01, 2023 10:34 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Tue Aug 01, 2023 11:39 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Tue Oct 31, 2023 5:40 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Wed Nov 01, 2023 10:16 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Wed Nov 01, 2023 11:34 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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