Pete's QBASIC Site

Hey guys, here are some considerations when tracking elapsed time.

Consideration #1:
If your program will never run passed midnight,
and therefore never run for more than 24 hours,
then the computation of elapsed time in seconds needs no additional computation. You may want to convert seconds to hours/minutes/seconds.

Consideration #2:
If your program can run passed midnight,
but not run for more than 24 hours,
then the computation of elapsed time has to detect that it has gone beyond midnight and adjust the elapsed time accordingly.
If you're using the TIMER function and have a start.time and an end.time, you detect having gone passed midnight when the end.time is less than the start.time. You can adjust for this by adding 86400 (seconds in a day 60*60*24) to the end.time before computing the elapsed time in seconds (end.time - start.time).
You may want to convert elapsed seconds to hours/minutes/seconds.

Consideration #3:
This is rarely required.
If your program can run passed midnight,
and can run for more than 24 hours,
then the computation of elapsed time must also involve the computation of elapsed days. This becomes a quite lengthy process which must take into consideration the following points:
* You will need to get a start date and an end date.
* Determine leap year for both dates.
* Convert a year/month/day to the equivalent total number of days from some offset or pivot year.
* Compute the difference in days between two dates (start date and end date).
* Having the difference in days and the difference in seconds (from TIMER), compute the total elapsed time in seconds. Note: This could be tedious.
* Having the elapsed time in seconds, you will probably want to convert to days/hours/minutes/seconds.
*****

... why dont you elaborate some more and then send it into QBXP...

btw, you have 1 more day to get it out pete... you can do it!

Nathan1993 wrote:... why dont you elaborate some more and then send it into QBXP....

Yeah, good idea, but perhaps a little too late. Why give Pete some more last minute work.
*****

well then why not document this and submit it to this sites tutors? That way it wont get COMPLETLY lost within the next month or 2.

As for #3, not needed, as you could just increase a var by 1 each second..

Then divide to get proper values...

Z!re wrote:As for #3, not needed, as you could just increase a var by 1 each second..

Then divide to get proper values...

Please explain your idea in more detail.
*****

Roughly: You might want to be even more accurate by taking the difference between timer and t!+1 and add it to the new time (or subtract). However, this method, as all other computer time measuring methods, is not accurate if left for long periods of time..

However, for a few days this method works fine...


Also note that I didnt do any midnight correction, which is required, as this is just an example..


Assuming secCount is a long you'd be able to get: 2147483647 seconds, or: ~24855 days (~70 years)

Z!re,

Very nice bit of code. What you are doing is tracking every single second that goes by (or elapses) in the variable secCount. I tested it and it runs fine.

If a program can afford to loop on the timer in this manner, then at any give time the elapsed time of the program running is contained in the variable secCount. Obviously, while doing other things, the program must get the timer at least once per second, otherwise secCounter will be out of phase.

Actually, this was not the idea of my post. I was referring to obtaining a starting date and time, and then an ending date and time, and computing the elapsed days/hours/minutes/seconds as the difference between them. This is much more difficult but doesn't have to worry about accessing the timer at least once per second.

Anyway, nice idea, I like it.
*****

Depends on the program I guess..

And you could make it so it can add the difference since last "call" to the secCount

Ofcourse then you'd most likely get rounding errors..

Z!re wrote:Depends on the program I guess..

And you could make it so it can add the difference since last "call" to the secCount

Ofcourse then you'd most likely get rounding errors..

After my last post, I started thinking about your approach and I came up with the same idea about adding the difference since the last "call" to the secCount. This allows you to only have to do a "call" to the timer at least once per day.

If you save the timer of the last call, and do an "if" before adding to see if we went past midnight, then this approach will handle every case needed. The secCount will have a grand total of seconds since we started, which can be easily converted to days/hours/minutes/seconds as you already showed.

If we keep the secCounter as double, then any rounding errors should be negligible.

Here's an implementation of Z!re's general purpose elapsed time logic. Thanks to you, Z!re, the above bit of code should handle any of the 3 considerations regarding computing elapsed time.
*****

How could this could be of use in a linux-clone?

grtz

Seb McClouth wrote:How could this could be of use in a linux-clone?

grtz

First tell me what a linux-clone is.
*****

alrighty... I'm talking about qbinux... I need a working time routine... that's all...

grtz

Seb McClouth wrote:alrighty... I'm talking about qbinux... I need a working time routine... that's all...
grtz

Ok, does qblinux have the equivalent of:
"TIMER - a function that returns the number of seconds elapsed since
midnight."

If so, than you should be able to lift my implementation of Z!re's logic above, which I tested for the simplest case (consideration #1).

BTW, what is the language that qblinux is coded in, and what operating system does it run under?
*****

QBinux is written in QB (hence the first 2 letters) and is not QB(L)inux.
Secondly, to see the source, Seb has graciously put it up for download in the MISC section of Pete's Site downloads. That should be mostly what you need.

QBinux is based on Novix, and as I made that, I know it's core is not "pausing" but based on looping.. (Think: INKEY instead of INPUT)

Implementing timing should be no problem..

Hey, Z!re,

I kinda expected some comment of my implementation of your idea.
*****

moneo wrote:Hey, Z!re,

I kinda expected some comment of my implementation of your idea.
*****

That is the first time I have ever seen you use an emoticon.

moneo, sorry..

Not much to say.. it's pretty much what I always used when I coded in QB.. Except I had it as a function with static variables in it..


And I have to agree with PQBC.. I've never seen you use an emoteicon before =)

Regarding my use of emoticons:

I used one on October 26th.

I hardly use them because the majority of my posts deal with coding problems and examples. Somehow emoticons just don't apply to code.
*****