gettimeofday to calculate elapsed when day changes - c

Question

The typical example that I see when trying to do measure elapsed time goes something like this:
#include <sys/time.h>
#include <stdio.h>
int main() {
struct timeval start, end;
gettimeofday(&start, NULL);
//Do some operation
gettimeofday(&end, NULL);
unsigned long long end_time = (end.tv_sec * 1000000 + end.tv_usec);
unsigned long long start_time = (start.tv_sec * 1000000 + start.tv_usec);
printf("Time taken : %ld micro seconds\n", end_time - start_time);
return 0;
}
This is great when it's somewhere mid day, but if someone were to run some tests late at night this wouldn't work. My approach is something like this to address it:
#include <sys/time.h>
#include <stdio.h>
int main() {
struct timeval start, end;
gettimeofday(&start, NULL);
//Do some operation
gettimeofday(&end, NULL);
unsigned long long end_time = (end.tv_sec * 1000000 + end.tv_usec);
unsigned long long start_time = (start.tv_sec * 1000000 + start.tv_usec);
unsigned long long elapsed_time = 0;
if ( end_time < start_time )
//Made up some constant that defines 86,400,000,000 microseconds in a day
elapsed_time = end_time + (NUM_OF_USEC_IN_A_DAY - start_time);
else
elapsed_time = end_time - start_time;
printf("Time taken : %ld micro seconds\n", elapsed_time);
return 0;
}
Is there a better way of anticipating day change using gettimeofday?

Answer 1

Despite the name, gettimeofday results do not roll over daily. The gettimeofday seconds count, just like the time seconds count, started at zero on the first day of 1970 (specifically 1970-01-01 00:00:00 +00:00) and has been incrementing steadily ever since. On a system with 32-bit time_t, it will roll over sometime in 2038; people are working right now to phase out the use of 32-bit time_t for this exact reason and we expect to be done well before 2038.
gettimeofday results are also independent of time zone and not affected by daylight savings shifts. They can go backward when the computer's clock is reset. If you don't want to worry about that, you can use clock_gettime(CLOCK_MONOTONIC) jnstead.

Answer 2

Why would you want to handle the case where end.tv_sec is less than start.tv_sec? Are you trying to account for ntpd changes? If so, and especially if you want to record only elapsed time, then use clock_gettime instead of gettimeofday as the former is immune to wall clock changes.

Answer 3

but if someone were to run some tests late at night this wouldn't work
That's an incorrect statement because gettimeofday is not relative to the start of each day but rather relative to a fixed point in time. From the gettimeofday manual:
gives the number of seconds and microseconds since the Epoch
So the first example will work as long as there are no jumps in time (e.g. due to manual time setting or NTP). Again from the manual:
The time returned by gettimeofday() is affected by discontinuous
jumps in the system time (e.g., if the system administrator manually
changes the system time). If you need a monotonically increasing
clock, see clock_gettime(2).

Answer 4

Is there a better way of anticipating day change using gettimeofday?
In addition to other problems identified in various answers, the following is also subject integer overflow when time_t is only 32-bit. Instead scale by a (unsigned) long long constant.
// unsigned long long end_time = (end.tv_sec * 1000000 + end.tv_usec);
long long end_time = (end.tv_sec * 1000000ll + end.tv_usec);
// Use correct specifier, not %ld for unsigned long long
// printf("Time taken : %ld micro seconds\n", elapsed_time);
long long elapsed_time = end_time - start_time;
printf("Time taken : %lld micro seconds\n", elapsed_time);
Tip: enables all compiler warnings.