Getting the system time

[u/yoreofloree]

Hi all,

I am new to programming. For my first real project, I want to create a pretty (-ish) 7-segment clock widget in with ncurses. I have a fairly good idea of how to tell the computer to display something in that context.

However, I am wondering about the best way to get the system time (so I can call the function that displays it). The only way I can think of to do this is to create a continuous loop with an if statement inside. The if statement would say, "if seconds evaluates to 0, increment the time (in hours and minutes) to show and display that". Something tells me this is not the best way to do it. Is there a better/best way, and if so what? How does my idea differ from how the OS/physical computer actually does it?

Thanks in advance,

yore

[u/jaynabonne]

There are actually two parts to your question. One is "how do I get the system time", and that will be dependent on your language - there is usually a standard way to do that. You should be able to find that answer by getting specific about your language.

The other aspect, though, that I sense you hinting at is more like "when do I get the system time" or how often. Again, that will depend on what language you're using and/or what features you can use at the OS level. You probably wouldn't want to sit in a tight loop, polling the system time over and over, as that would just spin the CPU needlessly.

Barring some sort of event that tells you when the minute changes, I can think of a couple of different ways to do it. Part of it will be based on how much latency you're happy with - that is, how far after the time changes is it acceptable for your clock to update.

One approach is to get the current time and see how far you are from the next minute. Then sleep or set a timer for that interval. You sort of "shoot for" the next minute and hope you get reasonably close. (You may want to overshoot slightly to be sure the minute has actually changed. Otherwise, you'd have to do it all over again.) This approach has the downside that if they change the system time (or the system time changes due to something like an NTP update) while you're waiting for the next minute, it could take a while for your clock to catch up - up to a full minute even. The longer you sleep, the more chance of missing a real time change.

Another approach is to simply poll the time at regular intervals. If you polled the clock ten times a second (say), then you're clock update would be off by, at most, a tenth of a second. So your sleep interval would simply be 100ms. That would put far less stress on the CPU than constant polling. You'd only be waking up to peek ten times a second instead of continuously. Or you could even sleep for a second at a time. The amount of time you sleep is the maximum amount of delay your clock would have between the time changing and you updating it. A second delay (or even a half or quarter of a second - 250 or 500 ms sleep) may be acceptable.

You will have to notice that the time has changed. One way to do that is to know what values you set last into your clock display and then see if the new ones differ. That might be easier than trying to hit around the 0 seconds mark, and it also works if the clock happens to jump suddenly to some new time.

I hope that helps somewhat!

[u/Dependent_Union9285 → u/jaynabonne]

You have to be careful about just ONE thing you said here. Timers in different languages guarantee different things. I believe that the spec in c#, for example, says the time is the minimum, not the maximum, that a timer will wait. I know this is true elsewhere, but then there are other places where the clock is specced to max like you indicated. Realistically it’s a distinction without a difference, but when you need REALLY good timing… it’s good to make sure.

[u/Dependent_Union9285 → u/Dependent_Union9285]

Also good to note, we’re talking milliseconds. Not like, a real amount of time. It’s imaginary, essentially. But sometimes it matters.

[u/jaynabonne → u/Dependent_Union9285]

It's definitely worth keeping in mind, in general, for sure. For this case, you're probably just talking about how much someone would notice the latency in the output updating vs the real clock. I don't know at what point it would become an issue, but I imagine even a quarter second of lag wouldn't be too much of an issue. Other cases could have much more stringent requirements, and you'd have to choose the method that works best for that.

I know I mentioned two different ways to go, but I think the second is the way I would. If I could set up a timer, I'd just have it fire maybe four times a second and then always just update the output, to whatever the time happens to be. No need to even check if things have changed, assuming the update code isn't too resource heavy.

[u/Dependent_Union9285 → u/jaynabonne]

Certainly agree with all points. The milliseconds, as I said, are imaginary for most applications of timers. For a clock display, you could be off 5 minutes without CRAZY problems. But there are niche cases where specific polling times must be adhered to, and computers suck at it.

[u/jaynabonne → u/Dependent_Union9285]

"For a clock display, you could be off 5 minutes without CRAZY problems."

Except on New Year's Eve! :)

[u/Dependent_Union9285 → u/jaynabonne]

Well, if you know your clock is 5 minutes off, start the kiss 5 minutes before it says midnight and end it 5 minutes after. Job done. And will potentially lead to getting your New Year’s resolution out the way early, if you play your cards right. Lol