9

I have a single line of code in my app server code which gets me the timestamp value using steady_clock as shown below:

uint64_t now = duration_cast<milliseconds>(steady_clock::now().time_since_epoch()).count();

Now we have two systems machineA which is running Ubuntu 12 (gcc 4.6.3 compiler) and machineB which is running Ubuntu 14 (gcc 4.8.2 compiler).

Now we compile our app server code using make on another Ubuntu 12 VM (which has 4.7.3 compiler) and then copy the tar file that gets generated to machineA and start our app server. After the start, the above line of code prints out value like this in machineA:

1439944652967

Now we also compile our same app server code using make on another Ubuntu 14 VM (which has 4.8.2 compiler) and then copy the tar file that gets generated to machineB and start our app server. After the start, the above line of code prints out value like this in machineB:

10011360

You see the difference right? I am confuse why this is the difference, I am not able to understand this? All the code and everything is same. Does anyone have any explanations about this and how can I fix it?

If needed, I can try adding some debug code to see what's wrong to figure out this issue.

user1950349
  • 4,738
  • 19
  • 67
  • 119

1 Answers1

20

I'm afraid there's been some confusion over what std::steady_clock is.

time_since_epoch gives the duration since the beginning of the clock, not necessarily the Unix epoch. steady_clock only guarantees to be monotonically increasing. This means that steady_clock will always be moving forward and that it will never decrease.

There is no guarantee about steady_clock representing anything meaningful. It can be the duration since the beginning of the program execution, the duration that the computer has been turned on, the duration since the most recent Tuesday, or pretty much anything as long as it continues to move forward.

In other words, steady_clock is not actually all that useful to tell real world time. It is only useful to measure the passage of time. It's uses could include any situation in which you have point in time A and point in time B and you're curious about the duration between them: benchmarking, progress estimates, etc.

If you're looking for real world time, you should look into std::system_clock, a clock that represents the time of the system (i.e. the operating system's time). It's great for telling time, but it's pretty pretty useless for measuring differentials since it is not guaranteed to be monotonic and is almost certainly not given daylight saving time, users adjusting their clocks, and other events that can alter real world time.

Corbin
  • 33,060
  • 6
  • 68
  • 78
  • 3
    In more general terms: "time" tells you what time it is, "clocks" simply go tick. – Mr. Llama Aug 19 '15 at 03:33
  • 1
    Good answer, but daylight savings time won't impact `system_clock`. `system_clock` typically tracks Unix time, which is the count of non-leap seconds since 1970-01-01 in the UTC timezone. – Howard Hinnant Aug 19 '15 at 15:08
  • @HowardHinnant It's not guaranteed to track a UTC unix time, and I'm almost certain that it's allowed to perceive DST. Per the standard: "Objects of class system_clock represent wall clock time from the system-wide realtime clock." (shamelessly lifted from [here](http://stackoverflow.com/questions/13263277/difference-between-stdsystem-clock-and-stdsteady-clock) since I don't have access to the standard at the moment). "Wall clock time" certainly changes depending on DST. – Corbin Aug 19 '15 at 15:42
  • 1
    You are correct, which is why I said "typically". I'm aware of 3 independent implementations of `std::chrono::system_clock` and all 3 track Unix Time as defined here: https://en.wikipedia.org/wiki/Unix_time – Howard Hinnant Aug 19 '15 at 15:55
  • Here is a link to the latest C++ working draft, should you find that helpful: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4527.pdf – Howard Hinnant Aug 19 '15 at 15:58
  • And here is a link to the proposal which got `` into C++11, should you find that helpful: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm – Howard Hinnant Aug 19 '15 at 16:00
  • @HowardHinnant Ah, sorry for the confusion then. I never meant to imply that the clock will definitely perceive DST but simply that the clock is allowed to see it and is thus unsafe to view as monotonic. – Corbin Aug 19 '15 at 16:27