If I have the following code:
Then this should produce something like 01:13:59.
If one second goes by and I try it again, then I should get 01:14:00
However ScriptFTP takes some amount of time to process each GETTIME() call. It is quite possible to get 01:14:59 instead. This is because there is a time delay between the call to the GETTIME(MIN) and the call to GETTIME(SEC).
From this I am assuming that you build strings right to left.
So the call to GETTIME(SEC) gets built (59), then the time flips to the next second, then the call to GETTIME(MIN) gets built (14), and we end up with the old second and the new minute.
Since I am comparing two time sets I end up with an elapsed time of 60 seconds rather than 1 second.
If one second goes by and I try it again, then I should get 01:14:00
However ScriptFTP takes some amount of time to process each GETTIME() call. It is quite possible to get 01:14:59 instead. This is because there is a time delay between the call to the GETTIME(MIN) and the call to GETTIME(SEC).
From this I am assuming that you build strings right to left.
So the call to GETTIME(SEC) gets built (59), then the time flips to the next second, then the call to GETTIME(MIN) gets built (14), and we end up with the old second and the new minute.
Since I am comparing two time sets I end up with an elapsed time of 60 seconds rather than 1 second.
Hello Bucket,
Thanks for the bug report.
Although this may sound weird, in fact, it is not a bug at all.
Let me explain, GETTIME is supposed to return the current time that the operating system reports in the exact moment GETTIME is run. If you make consecutive calls to GETTIME you should expect that each one takes some time (hundredths of a second, this is, much much less than a second, by the way).
If the precise moment when the clock changes from X:59 to (X+1):00 happens exactly between the two calls to GETTIME, well, this is unlikely to happen but... bad luck. ScriptFTP is not meant to be so smart, sorry. It is not able to know that you indeed wanted to know the same clock time across multiple calls to GETTIME. The solution, quite simple, call GETTIME only once:
Thanks for the bug report.
Although this may sound weird, in fact, it is not a bug at all.
Let me explain, GETTIME is supposed to return the current time that the operating system reports in the exact moment GETTIME is run. If you make consecutive calls to GETTIME you should expect that each one takes some time (hundredths of a second, this is, much much less than a second, by the way).
If the precise moment when the clock changes from X:59 to (X+1):00 happens exactly between the two calls to GETTIME, well, this is unlikely to happen but... bad luck. ScriptFTP is not meant to be so smart, sorry. It is not able to know that you indeed wanted to know the same clock time across multiple calls to GETTIME. The solution, quite simple, call GETTIME only once:
liked Script FTP? Try our other product Email Parser
Yes I had already come to this conclusion. I was just letting the changed script run for a while to see how you internally made up the suggested time string.
Hopefully you grab a date/time snapshot copy, then build up the string from that, rather than internally making several date/time calls.
Hopefully you grab a date/time snapshot copy, then build up the string from that, rather than internally making several date/time calls.
(hundredths of a second, this is, much much less than a second, by the way)Yes, but in a script which runs 24/7 I have already had two such occurrences.