-3

Does clock_gettime() work if the clock has NOT been set by clock_settime()? I have a situation where repeated calls to clock_gettime() returns the same time value (seconds). I seem to remember that I needed to first set the time with clock_settime(). Also do clock_gettime() and time() use the same time source?

clock_gettime(clockid_t clk_id, struct timespec *tp) - All  implementations  support  the system-wide real-time clock, which is identified by CLOCK_REALTIME.  Its time represents seconds and nanoseconds SINCE THE EPOCH.  When its time is changed, timers for a  relative  interval  are  unaffected,  but timers for an absolute point in time are affected.

time() - returns the time as the number of seconds SINCE THE EPOCH, 1970-01-01 00:00:00 +0000 (UTC).

Code is C, platform is Ubuntu 18.04. C++ is tagged in this question, because as far as I know C++ does not provide an method of obtaining high precision time (though C++20 does), and I will create a C++ version of my code.

Xofo
  • 1,256
  • 4
  • 18
  • 33
  • Are you checking it's return value for errors and handling appropriately, or just assuming it works? – Shawn Apr 15 '19 at 16:41
  • 1
    What does the documentation say? – stark Apr 15 '19 at 16:42
  • 1
    What is the code you are using? Also, read `man 3 clock_gettime`. – Artyer Apr 15 '19 at 16:42
  • What do you mean by "return the same value"? do they fill the same values in the `struct timespec*` argument? `clock_gettime(2)` only returns 0 or -1 for an error. Passing a NULL pointer for the `struct timespec*` argument is not an error. –  Apr 15 '19 at 17:34
  • 1
    @sjsam I do not think most C++ versions support fine-grained time. I am using this function in a C++ application. I know C++ 20 supports fine-grained time. From an pedantic perspective, yes this is not a C++ question, and I would not post it on comp.lang.c++ :D – Xofo Apr 15 '19 at 17:51
  • @xofo, The question is incomplete as it doesn't show any code. It could be that the return value indicates an error. `clk_id` could be referencing a clock that has a low resolution and `tp` isn't updating because it is being checked to often. Also you mention the seconds isn't updating or is it that every field of `tp` is identical? – fdk1342 Apr 15 '19 at 19:31

1 Answers1

3

clock_settime sets the time for the entire computer. Only system administration tools (e.g. the GNOME Control Center) and time synchronization daemons (e.g. ntpd) should ever need to call it. It requires superuser privileges; most programs cannot successfully call it.

If clock_settime (or one of the older APIs that do the same job) has never been called on a particular computer, the values returned by clock_gettime may well be wrong by comparison to some authoritative source of the current time. However, the clocks should all still be running, whether or not the time is accurate. I'm not aware of any API, on Linux or otherwise, to stop the system clock.

However however, depending which clock ID you're using, getting the same value from two consecutive calls to clock_gettime may be normal (not a bug or a problem). For instance, this may happen if the interval between the two calls is shorter than the resolution of the clock, as reported by clock_getres.

zwol
  • 135,547
  • 38
  • 252
  • 361
  • This is the answer - Time must first be set on the host computer. Question - Do time and clock_gettime use the SAME clock (time source)? – Xofo Apr 15 '19 at 17:52
  • 1
    @Xofo I think you misunderstood the answer. What I am saying is that `clock_gettime` should produce times that advance _whether or not_ the time has already been set (but watch out for the resolution). Please don't ask new questions in the comments on answers; post another question instead. – zwol Apr 15 '19 at 18:34
  • I understood your answer, and you answered my question. Time must FIRST be set. getimeofday is deprecated though. – Xofo Apr 15 '19 at 18:38
  • 1
    I don't understand how you got from "clock_gettime should produce times that advance __whether or not__ the time has already been set" to "time must __first__ be set". – zwol Apr 15 '19 at 18:45
  • My question was answered very well by you - Time must first be set . "clock_settime sets the time for the entire computer" ... someone has to set it, and this resolved the behavior I was seeing. – Xofo Apr 15 '19 at 19:25
  • 2
    @Xofo Time does not need to be set via `clock_settime()` for `clock_gettime()` to return a valid `tp`. It just may be the wrong time in comparison to the actual local time. For example an embedded Linux system with no network access and no real-time clock to set an initial clock time. – fdk1342 Apr 15 '19 at 19:26
  • 1
    @Xofo If you observed that successive calls to `clock_gettime` were returning the same value, and then you called `clock_settime`, and then you observed that successive calls to `clock_gettime` were returning different values, then either you were using some operating system very different from Unix/Linux/Posix, or you were using some clkid very different from CLOCK_REALTIME, because basically, what you observed is impossible. – Steve Summit Apr 15 '19 at 20:09