Programming

13371 readers

2 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago

MODERATORS

alyaza@beehaw.org

Hexorg@beehaw.org

remington@beehaw.org

[very noob question] how can i calculate the hours passed between 2 different times and between days in C (lemmy.ca)

submitted 1 year ago by Vilian@lemmy.ca to c/programming@beehaw.org

9 comments fedilink hide all child comments

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 are viewing a single comment's thread
view the rest of the comments

[–] juni@skein.city 1 points 1 year ago (1 children)

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.

[–] tunetardis@lemmy.ca 0 points 1 year ago (1 children)

Okay, I've read up on this a bit an you raise some valid points.

For whatever reason, posix has decided that CLOCKS_PER_SEC must be exactly 1000000 on every system that wants to comply. That doesn't leave much room on a 32-bit system for maximum clock duration. It will wrap around well before the 10 hours the OP was giving by example.

The other is I gather on some systems, clock() may be measuring the uptime of a particular process, which is not necessarily the same as real world time in multicore environments. (Fwiw I'm on a Mac where I don't think it works that way? You would need some special apis to get that kind of info.)

I'm trying to think of the last time I programmed straight C and used time.h and the like. It was probably in developing scientific instrumentation? iirc the clock in that case was keyed to the VBL refresh of the display, meaning CLOCKS_PER_SEC would have been something like 60 Hz. And I doubt time() would have yielded any useful value. I wonder what the OP's use case is?

[–] juni@skein.city 2 points 1 year ago

Most of my hobby programming is in ANSI C and C99, so I'm unfortunately far too aware of the weird and counter-intuitive things the C and POSIX standards say. :P

clock() is fantastic for sub-second timings, such as deltatimes in games, or peripheral synchronization, which matches the use case you mention very well. I recommended time() over it as OP's use case is for calculating the amount of hours a user has had their software open, and unix timestamps are the perfect mechanism to do that in my opinion.