Counter losing time?

HI All.

Have what is probably a silly question, but figure I would ask.

I have a counter to check how many hours, minutes, seconds have gone by since the start of the timer, where it uses a timer, in multiple mode, to count up. After 60 seconds, increments minutes, after 60 minutes increments hours.

When I run the program, the time that is shown as having passed does not match my computer time. I set the program, in the App to run a shell and fire caffenated so that the computer doesn’t sleep while the program is running… but the time is still off. Or more accurately the time counted + the start time is not the same as the clock time.

Has anyone run into something similar?


How are you tracking the time?

Keep in mind that a Timer’s Period is not guaranteed, it’s a minimum, so if the Period is set to, say, 200 (milliseconds), the Timer might fire after 200 ms on one pass, 250 ms on another, or even much longer if the main thread is tied up. If you are just counting the passes, your measurement will be off.

Hi there.

I am tracking the time (as such) by knowing for example that I started a count at 10:00 am.
If my counter is at 5 minutes, 10 seconds I would expect my computer clock to show 10:05 (with a margin for human error as it were.)

But my counter will show for example 10 minutes 5 seconds passed via the timer, but the clock will show, again as an example, 10:30. I have “caffenated” my program, and will start looking for logic errors on my part to see if I can find anything I did wrong.

Just curious as it were.


You can post your code to get another set of eyes. Sometimes others will see things, even obvious things, that you miss because you’re too close to it. (This happens to everyone. Well, not me, of course. Never me…)

1 Like

This is an example of the offsetting that can happen with what Kem described with the “minimum time” aspect of how a Timer fires. If your program does not have priority, or is busy doing things it can take longer than the Period set for the Timer to fire - offsetting your counter.

If you need time-accurate tracking, why not just store the DateTime object of the start time, and compare to DateTime.Now when you’re done?


Why not use DateInterval?

1 Like

I’d go so far and say that’s the only valid way to go. Store start time with needed precision and store stop time with same precision and compare both.

Hi All. Thank you for those responses.

I did find something that, well was kind of embarrasing… but if we new everything, we wouldn’t have wonderful forums, and people willing to help, right.

The biggest problem I have (had??) was that I was counting from 0 to 60 seconds… which from what I saw was a count of 61… I set the comparative value to 59 before it added 1 to minutes which definitely tightened things up.

There was a small difference, but not enough to talk about.

My only existing issue is that for some reason, even though I have turned off putting the computer to sleep in my mac system preferences, and have run the caffenated item in my app events, when the app opens, as soon as the computer goes into screen saver mode, and the display gets shut off, the program seems to stop counting.

I am, for giggles, running a video stream to keep my computer from sleeping, and I’ll see how the timer wants to act.

As to the other questions, I do the datepicker thingie, and it works just fine even if the computer screensaver has ended. The stop watch item has to do with me trying to keep time working on customer troubles, so I get a more “accurate” billing count.


It will indeed stop counting. The Timer is tied to the Main Thread of your App.
And it’s ineffective to keep a timer running and eating ressources while your System already has a timer for you running.
Preventing your System from standby/sleep/… just to keep your own timer up and running is not very environmental friendly. :wink:

Just keep the start and stop values of your Systems timers and your good to go. :slight_smile:

You can store a DateTime property on the window set it:

lastDateTime = DateTime.Now

When the window gets it’s activate event you restart the timer and get the last datetime, then get the difference between them using DateInterval:

Var now As DateTime = DateTime.Now
Var i As DateInterval = (now - lastDateTime)
// Report it in HH:MM:SS format:
MessageBox "Your difference is: " + i.Hours.ToString +":"+ i.Minutes.ToString +":"+ i.Seconds.ToString 

There is NO need to keep the timer active since you don’t need the info when the screensaver is on right? But if you really require it MBS has a plugin that will allow you to keep the activity going, timers, sockets etc.

Ah, this dear App Nap strikes again, it seems…

Probably what you’re seeing is Apple’s behaviour of apps put in the background (which is what a screen saver does to other apps) being suspended (or slowed down) to preserve CPU/battery.
Look there:


and tell us whether that solves your issue.