argumentum Posted May 21, 2021 Share Posted May 21, 2021 (edited) in the post Date macros safe to use?, I started to dig into the possibilities. And within the UDF, yes, there is a possibility of 1 in a zillion, or just plain overwhelmed CPU that a time calculation be ugly wrong. So I propose to change all macro ( or most of 'em ), to "kernel32.dll, GetLocalTime". And since I thought of it, might as well get it done. Please find attached the new beta for evaluation. Thank you very much. I'll now go get a beer. oops: I now realized that I did not account for the leading zero on single digit numbers ( after the beer ) Fixed.Opps again: Forgot error checking. Done ok, this one can be downloaded Date.au3(3.3.15.4_proposal_v3).zip Edited May 21, 2021 by argumentum oops JockoDundee 1 Follow the link to my code contribution ( and other things too ). FAQ - Please Read Before Posting. Link to comment Share on other sites More sharing options...
JockoDundee Posted May 21, 2021 Share Posted May 21, 2021 (edited) 1 hour ago, argumentum said: yes, there is a possibility of 1 in a zillion, For me, it was much less, around 1 in 13.6 million. Good idea, arg, definitely needed to be fixed! For anyone else who wants to test how long before the current production UDF glitches: #include <Date.au3> Local $sNow, $sThen, $iCalls=0, $htimer=TimerInit() Do $sThen=$sNow $sNow=_NowCalc() $iCalls+=1 Until $sNow<$sThen ConsoleWrite("Time jumped from "& $sNow &" to "& $sThen &@CRLF) ConsoleWrite("Run Time: "& Round(TimerDiff($htimer)/1000,3) &@CRLF) ConsoleWrite("Calls Made: "& $iCalls &@CRLF) *using the production UDF Time jumped from 2021/05/20 21:01:00 to 2021/05/20 21:01:59 Run Time: 50.323 Calls Made: 13602962 Edited May 21, 2021 by JockoDundee argumentum 1 Code hard, but don’t hard code... Link to comment Share on other sites More sharing options...
jpm Posted May 21, 2021 Share Posted May 21, 2021 9 hours ago, argumentum said: in the post Date macros safe to use?, I started to dig into the possibilities. And within the UDF, yes, there is a possibility of 1 in a zillion, or just plain overwhelmed CPU that a time calculation be ugly wrong. So I propose to change all macro ( or most of 'em ), to "kernel32.dll, GetLocalTime". And since I thought of it, might as well get it done. Please find attached the new beta for evaluation. Thank you very much. I'll now go get a beer. oops: I now realized that I did not account for the leading zero on single digit numbers ( after the beer ) Fixed.Opps again: Forgot error checking. Done ok, this one can be downloaded Date.au3(3.3.15.4_proposal_v3).zip 11.13 kB · 4 downloads Thanks I integrate it in the next beta argumentum 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now