Author |
Topic: Upper limit of TIME variable (Read 565 times) |
|
marcellooct1942
New Member
member is offline
Posts: 3
|
 |
Upper limit of TIME variable
« Thread started on: Jan 31st, 2014, 4:39pm » |
|
When TIME function is used in programs that stay active continuously for a long time, its value may reach the maximum value for integers that is 2147483647. This
corresponds to 21474836 seconds, i.e 5962 Hours, i.e. 248 days.
After that period will TIME variable go to 0?
Since I have programs running continuously 24H a day, normally I use to reset the TIME variable at every midnight, by forcing it to 0 and by also forcing to 0 all other variables used for comparison with TIME for
interval evaluation purposes.
Is it a necessary precaution or it is just a useless complication?
Regards
Marcello
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Upper limit of TIME variable
« Reply #1 on: Jan 31st, 2014, 7:36pm » |
|
on Jan 31st, 2014, 4:39pm, marcellooct1942 wrote:When TIME function is used in programs that stay active continuously for a long time, its value may reach the maximum value for integers that is 2147483647. This corresponds to 21474836 seconds, i.e 5962 Hours, i.e. 248 days.
After that period will TIME variable go to 0?
|
|
TIME is effectively an unsigned value (you can use the FNuint function here to do the conversion if required) so your calculation is incorrect: it won't run out of range until after 2^32 centiseconds, which is approximately 497 days.
After that 497 day period it will probably wrap around from &FFFFFFFF to &00000000, but I wouldn't want to be 100% certain without carrying out the test, which isn't really practical!
Considering that we are talking about Windows, I don't think that a program running continuously for more than 16 months is a realistic possibility!
Just a word of caution: when running in BB4W version 6.00a (or later), code such as T% = TIME will fail after about 248 days since the returned value will go out-of-range for a 32-bit signed integer. To future-proof your code, copy TIME into a variant variable.
Richard.
|
|
Logged
|
|
|
|
marcellooct1942
New Member
member is offline
Posts: 3
|
|
Re: Upper limit of TIME variable
« Reply #2 on: Feb 1st, 2014, 09:31am » |
|
Thank you Richard for the explanation.
I may agree that a continuous run of 16 months is unlikely to happen, but I have programs running since 5 years at customer premises of which I have no control.
I presume the customer has restarted the program sometime in the mean time but I cannot be certain about that.
In effect I am using statements like T%=TIME and that is why I was concerned about the top limit.
Just for precaution all variables concerned with comparison against TIME are zeroized once a day as well as TIME is.
May be in the future I could just verify the current TIME value and then take some action only if its value exceeds &07FFFFFF.
Thank you again
Marcello
|
|
Logged
|
|
|
|
JGHarston
Junior Member
member is offline
Gender: 
Posts: 52
|
|
Re: Upper limit of TIME variable
« Reply #3 on: Feb 5th, 2014, 09:05am » |
|
on Feb 1st, 2014, 09:31am, marcellooct1942 wrote:Just for precaution all variables concerned with comparison against TIME are zeroized once a day as well as TIME is.
|
|
What I prefer to do is not zero TIME, but subtract 24*60*60*100, something like:
REPEAT
T%=TIME
IF T%>=8640000 THEN TIME=TIME-8640000
UNTIL T%<8640000
|
|
Logged
|
|
|
|
marcellooct1942
New Member
member is offline
Posts: 3
|
|
Re: Upper limit of TIME variable
« Reply #4 on: Feb 5th, 2014, 09:13am » |
|
Good point.... I accept the suggestion.
The constant shall be subtracted both from TIME and from all the variables used in the program that are compared against TIME.
Thank you
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Upper limit of TIME variable
« Reply #5 on: Feb 5th, 2014, 12:05pm » |
|
on Feb 5th, 2014, 09:05am, JGHarston wrote:| What I prefer to do is not zero TIME, but subtract 24*60*60*100 |
|
Yes, and of course you can choose to subtract anything convenient - it doesn't have to be a period of one day. You could for example round it up to 10000000 centiseconds.
But I still think that, since (unsigned) TIME won't 'wrap around' until the program has been running for more than 16 months, it's hardly worth bothering.
Richard.
|
|
Logged
|
|
|
|
|
