hello, i’m new to programming in i’m trying to solve this exercise in C, basically it’s the amount of passed hours between the start of a game and it’s end, if the game started at 16 and ended at 2 the result is a game with 10 hours(in different days) i know i can to it more manually, but i wanted to somehow use the <time.h> to learn how to use a header etc, can someone help me?, thank you all
You save the unix timestamp at the beginning of the game and the end of the game (or use the current one). With this timestamps you can use functions to calculate length etc. For example https://cplusplus.com/reference/ctime/difftime/ You then can convert those into a better format. More info here https://cplusplus.com/reference/ctime/
Also chatgpt could help in those cases, if you don’t want to wait for a answer on here :P
Take 10 minutes to watch this video, then follow his advice. get a library that handles time and date and use it.
The thing is to take 2 time stamps: one at the beginning and one at the end of the game. Then you subtract the beginning value from the end to get the elapsed time.
In terms of <time.h>, you probably want to call clock() to get these time stamps.
clock_t beginTime = clock();
And later:
clock_t endTime = clock();
double elapsed = (double)(endTime - beginTime) / CLOCKS_PER_SEC;
That would give you the time in seconds, which you could make into hours by dividing it further by 3600.
(Note: It’s been a long time since I’ve programmed straight C so I may be off on something here? In C++, you would want to use std::chrono::steady_clock::now() to get your time stamps, even though clock() still exists.)
This is correct, however it is important to note that the C standard allows arbitrary values at the beginning of the program. The manpage does a better job explaining it.
Doing a bit of research, it looks like the POSIX time_t time(time_t *dest) function (man) is available on Windows (see here). So I would recommend that over clock_t clock(void) as it will operate more consistently across platforms.
The arbitrary values at the beginning of the program is the reason you want to measure a difference rather than an absolute time. Like you don’t want to simply go (double)clock() / CLOCKS_PER_SEC at the end of the program. That would only work if you knew for certain that the clock started at 0 on program launch. Some operating systems may ensure this. Others may only zero it when the CPU is booted, for example. So it’s just not safe to work with absolute times, but differences between time stamps should still behave consistently across platforms.
Now, the problem with time() and friends is they represent the kind of time displayed by your computer. In most cases, this should work fine, but occasionally, the OS may adjust this time for a number of reasons. It may be jumping ahead or back due to daylight savings, for example, or adding/losing some seconds as it syncs the computer clock to an NTP server someplace. What you want to use to avoid such shenanigans in measuring time elapsed is a steady clock which ticks along regardless of what the OS decides to do. I think clock() is your best bet for that in plain C? (It also may have a higher resolution than time(), though that’s not super important if you’re only worried about counting hours.)
Using clock() solely for delta values is absolutely a valid approach, as stated. The issue is that clock_t may not be large enough of some systems to safely keep you from an overflow, especially with arbitrary values. Additionally, some systems will include the time children processes were alive in subsequent clock() calls, furthering possible confusion. These are reasons why I would avoid clock() in favor of time(), even though your concerns are absolutely valid.
At the end of the day you have to determine which style of unpredictability you want to work around. Dealing with the times(), clock(), and clock_gettime() class of functions opens you up to managing what the kernel considers time passed, and what is accumulated vs what is not. While using time() can have shifts in time according to upstream NTP servers, as well as daylight savings time.
I would also make the argument that if an NTP server is adjusting your time, it is most likely more accurate than what your internal clock (CMOS or otherwise) was counting, and is worth following.
