15

I'm using the steady_clock for saving the time stamp of some messages. For debug purpose is usefull to have the calendar (or something similar).

For other clocks ther's the static function to_time_t, but on GCC (MinGW 4.8.0) this function is not present.

Now i print something like:

Timestamp: 26735259098242

For timestamp i need a steady_clock so I cannot use system_clock or others.

Edit The previous print is given from the time_since_epoch().count()

pyCthon
  • 11,746
  • 20
  • 73
  • 135
Elvis Dukaj
  • 7,142
  • 12
  • 43
  • 85
  • What would be the desired `time_t` value of a `steady_clock::now().time_since_epoch()` of `0.12 milliseconds`? Define the conversion and you will have your answer. – Cubbi Aug 21 '13 at 15:51
  • 1
    `(to|from)_time_t` is meaningful only to system clocks. A `high_resolution_clock`, for example, may not be able to support the range of the whole `time_t`. – kennytm Aug 21 '13 at 15:51
  • 2
    Has it been about 7 hours 42 minutes since you rebooted your computer? – Howard Hinnant Aug 21 '13 at 16:13
  • I don't know but can be something similar. So that number can be the micro seconds since boot – Elvis Dukaj Aug 22 '13 at 12:08
  • 2
    On my system, which is not gcc/mingw, the epoch of `steady_clock` is nanoseconds since boot. It might be the same on your system. An experiment to find out would be easy for you. – Howard Hinnant Aug 22 '13 at 14:39

1 Answers1

29

Assuming you need the steady behavior for internal calculations, and not for display, here's a function you can use to convert to time_t for display.

using std::chrono::steady_clock;
using std::chrono::system_clock;

time_t steady_clock_to_time_t( steady_clock::time_point t )
{
    return system_clock::to_time_t(system_clock::now()
                 + duration_cast<system_clock::duration>(t - steady_clock::now()));
}

If you need steady behavior for logging, you'd want to get one ( system_clock::now(), steady_clock::now() ) pair at startup and use that forever after.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • The frequency of system_clock might actually deviate from the frequency of steady_clock, due to clock alignments by ntp etc. Hence, "and use that forever after" might not be a good idea. Or otherwise someone might just change the clock manually. – sstn May 30 '14 at 09:29
  • 3
    @sstn: differences in frequency are taken care of by the chrono operator definitions. And you have to use just one basis, if you want a steady clock. Incorporating manual or ntp updates makes a clock unsteady, potentially even monotonic. – Ben Voigt May 30 '14 at 11:55
  • If one needs to relate logs between different systems then steady_clock_to_time_t is also what one wants so the log incorporates time adjustments after the application starts up. – Igor Bukanov Feb 18 '17 at 17:08
  • @Igor: If your goal is to incorporate time adjustments, why are you using `steady_clock` in the first place? – Ben Voigt Feb 18 '17 at 17:49
  • 3
    @BenVoigt In my application I use`steady_clock` to set various expiration times based on duration. Those must not be affected by the wall clock changes. Yet in the log I want to have the wall clock to relate the event time between different systems. – Igor Bukanov Feb 19 '17 at 12:30
  • 11
    This doesn't work for me on MSVC (Windows 10, 64-bit); there is a compilation error. To make it work, I had to do `return system_clock::to_time_t(system_clock::now() + duration_cast(t - steady_clock::now()))`. Note the extra `duration_cast`. – Bernard Mar 21 '17 at 14:51
  • Thanks for posting this :) – Short May 26 '19 at 14:28
  • I also had to apply @Bernard's fix using the latest build from clang – Short Jul 05 '19 at 01:27
  • There are some differences in the 'goals'. If you want a time accurate log, then you need to adjust via the actual time. Ie, with a static 'steady_clock::now()' and a program running over day light saving change, the log would be monotonic, but out by 1h over local time. This is an unreconcilable difference between steady and system clock. The answer keeps monotonic behavior and gives a semi-readable human output, but if interpreted in the wrong way (as a real local time), then it will be in error for a long running process. – artless noise Mar 20 '22 at 17:59
  • 1
    @artlessnoise: If you want steady behavior in a log, you discard the notion of daylight savings time (for example use UTC). That would go with the suggestion in my last paragraph. The main answer assumes that the log needs to be human-readable local time, and needs to be converted from a steady clock, but does not itself need to be monotonic (and won't be during a DST change or resync of the system_clock with a network reference) – Ben Voigt Mar 21 '22 at 15:02