17

Apart from the difference of precision, what are the differences between struct timeval and struct timespec? If I need less precision than µs (say, milliseconds), why would I use one over the other?

On my compiler (gcc for ARM):

/* POSIX.1b structure for a time value.  This is like a `struct timeval' but
   has nanoseconds instead of microseconds.  */
struct timespec
  {
    __time_t tv_sec;        /* Seconds.  */
    __syscall_slong_t tv_nsec;  /* Nanoseconds.  */
  };

/* A time value that is accurate to the nearest
   microsecond but also has a range of years.  */
struct timeval
  {
    __time_t tv_sec;        /* Seconds.  */
    __suseconds_t tv_usec;  /* Microseconds.  */
  };

With both __syscall_slong_t and __suseconds_t defined as a "long word".

Julien-L
  • 5,267
  • 3
  • 34
  • 51
  • 4
    You use the correct structure for the system calls you're going to use — `struct timeval` for `gettimeofday()` (and `select()`), and `struct timespec` for `clock_gettime()`. For internal processing, you can use either or both, as is convenient for you. Conversion between the two is relatively painless; input and output requires a modicum of care (mainly making sure leading zeros for the fractional part are printed and scanned correctly when necessary). BSD and Mac OS X provide some primitive arithmetic and comparison facilities for `struct timeval`; there is no analogue for `struct timespec`. – Jonathan Leffler Jul 07 '15 at 17:43
  • 1
    You should look at [Why C has so many different types](http://stackoverflow.com/questions/31157164/) which is also asking about `struct timeval`. – Jonathan Leffler Jul 07 '15 at 17:47

3 Answers3

21

I think it's really just a matter of API [in]compatibility. POSIX-y calls like pselect() and clock_gettime() use struct timespec. Various filesystem calls like utimes(), and some assorted Linux calls like gettimeofday() and select(), use struct timeval. Broadly generalizing from a few man pages, I suspect that struct timeval has a BSD legacy whereas struct timespec is POSIX.

If you're doing interval measurements, there's no reason not to leverage the extra precision from clock_gettime() — though beware that it's usually hardware, not the header file, that limits your measuring precision. Dividing by a million for display purposes is hardly better or worse than dividing by a thousand. (Also, Mac OS X prior to 10.12 did not support clock_gettime().)

But if you're doing lots of file time manipulation, it might make more sense to use the struct timeval used in APIs like utimes(). struct timeval also has some comparison functions on Linux, BSD and Mac OS X, e.g. timercmp(), timersub() (again, see man pages).

I'd make the decision based on the APIs you intend to use, rather than on the structures themselves. (Or write a wrapper class with conversion methods if necessary.)

Simon Kissane
  • 4,373
  • 3
  • 34
  • 59
lyngvi
  • 1,312
  • 12
  • 19
  • 3
    My current version of Mac OS X (10.12) does support `clock_gettime`. – ioquatix Jun 27 '17 at 23:21
  • 1
    @ioquatix `clock_gettime()` has been added in 10.12, before that version you could use `mach_time` to get a high precision, monotonic clock. – Mecki Sep 11 '19 at 16:17
3

Both are AFAIK defined for POSIX.1-2001, so from a portability point of view, it doesn't matter which one you use. The most simple answer is: use whichever you need for the API you intend to call.

There COULD be a platform-dependent size benefit using struct timeval:

The type suseconds_t shall be a signed integer type capable of storing values at least in the range [-1, 1000000].

in struct timespec the second member is of type long. An int would be enough on a 32bit platform to fulfill the suseconds_t requirements. But, on a 64bit system, time_t is typically 64 bit, thus forcing the structure to pad to 16 bytes anyway. So a size benefit is -- improbable.

  • 5
    Yes, both are still POSIX but since POSIX.1-2008+TC1 some functions that use `struct timeval` are marked as obsolescent. `struct timespec` is also part of the ISO C standard since C11. – cremno Jul 07 '15 at 17:41
2

Personally, I use neither one. I prefer to express time as a simple int64_t because that makes time calculations dead simple and if you have to, converting back to struct timeval or struct timespec is no problem either. Even if you want a precision of nanoseconds, int64_t can express a span of almost 585 years. If you just need milliseconds, you have a span of almost 585 million years.

Mecki
  • 125,244
  • 33
  • 244
  • 253
  • Only problem is time_t is not specified by the standard as being signed OR unsigned or integral OR floating point. And it doesn't specify a MAX limit either. So conversion is actually a pain – Daniel Mar 25 '23 at 09:36