28.8 Million Millisecond Timer Question

I have no code written for the question regarding timers. Reason being 28.8 Million milliseconds.

It seems all examples and documentation discuss timers in milliseconds. I have an instance where I need to time a period of 8 hours before an action is taken. In milliseconds this is 28,800,000 milliseconds! Accuracy to the second isn’t important: being off by several seconds in eight hours would be fine.

My question is over such a long time period would I still use milliseconds or is there a different way to time 8 hours? If there is a different way to go kindly point me in the right direction.

Thank you. Jim Backus

I have set a timer successfully for 24 hours and it operates fine. I don’t know how close to exactly 24 hours it occurs, but I know it does work (it fixed a bug).

I wrote my code so that the hours number was easy to spot:

moShared = new Timer
moShared.Enabled = true
moShared.Period = ((1000 * 60) * 60) * 24
moShared.RunMode = Timer.RunModes.Multiple

moShared.Reset
2 Likes

Thank you, Tim. Appreciate the quick reply.
Jim

You can also use constants for readability. Something like this:

const kSeconds as integer = 1000
const kMinutes as integer = kSeconds * 60
const kHours as integer = kMinutes * 60
const kDays as integer = kHours * 24

moShared.Period = 8 * kHours
3 Likes

You can also get the DateTime.Now and store it in a variable when a timer starts.

Set a timer for one second, and every second compare the date interval between when you started the timer, and the DateTime.Now. When it hits 8 hours, it’s done.

I have a timer app that needs to be accurate to the second, so I check the elapsed time every 1/10th of a second.

1 Like

Why wouldn’t you simply set a timer for 1 second and check that? Or do your events need to be aligned to the exact second?

I need them aligned to the exact second. In my case it updates a text countdown timer and two graphical timers.

Interesting challenge.

Not to second-guess your approach - but how about this: test every 1/10th of a second until you’d established alignment, and then abandon the 1/10th timer and set up a 1 second timer? It should be guaranteed to hit very accurately.

Timers can be delayed by other events, though.

2 Likes

What I do if the event is more than a second or so in the future is to set the timer to fire at 80 or 90% of the desired elapsed time. The timer will then evaluate how much time is left and reset itself to a desirable time, designed so it doesn’t overshoot. Rinse and repeat. Each iteration, the Period get’s smaller and smaller, until you hit a very accurate time.

Eg., if the timer should fire in an hour, I set it to 55 minutes and then hone in on the proper time from there. Timers are only approximate. They will never be exact.

3 Likes

It does few tiny calculations when the timer fires.
How much time has elapsed.
How much time is left.
It creates a timestamp string. If the new timestamp is different than the previous one, then it updates the timer text and graphical stuff.

Timers are not 100% accurate. But using timers to compare DateTimes makes it very accurate.

Maybe 0.5, or 0.25 second timers might be good enough/close enough, but 0.1 second timer is what I’ve gone with.

If accuracy to within milliseconds is crucial, a preemptive thread could be used too. It could sleep to within, say, 100 ms, then continuously loop until it hits the target time. If it needs to trigger something on the main thread, it could issue an AddUserInterfaceUpdate before the target time, and that would trigger the loop in the main thread until the target time is reached.

I think it would easy to write a class like that.

Yes, absolutely. I do that for a program controlling signal generators, and while I don’t need that precision, I try to match the intended run time for a frequency as closely as possible. System.Microseconds is your friend in this case.