35

std::chrono::time_point::time_since_epoch() returns a duration, referred to some time_point in the past. When is such a time_point? It depends on the C++ implementation or it's defined by the C++ standard? Or it is a de facto standard to set the epoch to 1 January 1970 UTC?

Paolo M
  • 12,403
  • 6
  • 52
  • 73

1 Answers1

56

It is a function of both the specific clock the time_point refers to, and the implementation of that clock. The standard specifies three different clocks:

  • system_clock
  • steady_clock
  • high_resolution_clock

And the standard does not specify the epoch for any of these clocks.

Programmers (you) can also author their own clocks, which may or may not specify an epoch.

There is a de-facto (unofficial) standard that std::chrono::system_clock::time_point has an epoch consistent with Unix Time. This is defined as the time duration that has elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds.

Fwiw, here is a date/time library which takes advantage of this de-facto standard.

There is no de-facto standard for the other two std-specified clocks. Additionally high_resolution_clock is permitted to be a type alias for either system_clock or steady_clock.

On OS X, high_resolution_clock is a type alias for steady_clock, and steady_clock is a count of nanoseconds since the computer booted (no relationship whatsoever to UTC).

Update

The draft C++2a spec now says for system_clock:

Objects of type sys_time<Duration> measure time since (and before) 1970-01-01 00:00:00 UTC excluding leap seconds. This measure is commonly referred to as Unix time. This measure facilitates an efficient mapping between sys_timeand calendar types (27.8). [Example: sys_seconds{sys_days{1970y/January/1}}.time_since_epoch() is 0s. sys_seconds{sys_days{2000y/January/1}}.time_since_epoch() is 946’684’800s, which is 10’957 * 86’400s. —end example]

Additionally, C++2a introduces utc_clock, tai_clock, gps_clock and file_clock. These clocks also have well-defined epochs as one can clock_cast time_points from one clock to another among these and system_clock.

The file_clock epoch will not be portable, but you will still be able to relate its time_points to the civil calendar.

utc_clock is like system_clock, except that it does not ignore leap seconds. For example:

#include <chrono>
#include <iostream>

int
main()
{
    using namespace std::chrono;
    auto s1 = sys_days{December/31/2016} + 23h + 59min + 59s;
    auto s2 = sys_days{January/1/2017};
    auto u1 = clock_cast<utc_clock>(s1);
    auto u2 = clock_cast<utc_clock>(s2);
    std::cout << s2 - s1 << '\n';
    std::cout << u2 - u1 << '\n';
}

Outputs:

1s
2s

Update

Link to the now specified (C++20) system_clock epoch: http://eel.is/c++draft/time.clock.system#overview-1

Objects of type system_­clock represent wall clock time from the system-wide realtime clock. Objects of type sys_­time<Duration> measure time since 1970-01-01 00:00:00 UTC excluding leap seconds. This measure is commonly referred to as Unix time. This measure facilitates an efficient mapping between sys_­time and calendar types ([time.cal]). [ Example: sys_­seconds{sys_­days{1970y/January/1}}.time_­since_­epoch() is 0s. sys_­seconds{sys_­days{2000y/January/1}}.time_­since_­epoch() is 946'684'800s, which is 10'957 * 86'400s. — end example ]

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • 1
    For future readers: Do you have a list of links to official documentation where one could check if this is still true? – MikeMB Jan 16 '17 at 11:32
  • 1
    Here are all of the C++ papers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ Among these documents will be drafts of the C++ standard which contains the official specification for ``. The official C++14 specification is http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n4141.pdf but it is not freely available. However http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf is the next draft after that and should be close enough. The current draft of C++17 is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4618.pdf – Howard Hinnant Jan 16 '17 at 15:16
  • Thank you very much, I should have been more precise: I meant if there is any documentation on the de-facto behavior of the different standard library implementations with regard to `std::chrono::system_clock`. That would avoid the necessity to write platform specific unittests to verify that behavior. – MikeMB Jan 16 '17 at 18:01
  • 5
    Nothing official. Here is a proposal that does many things, and one of those things is to standardize the epoch of `system_clock`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0355r1.html But it is just a proposal, and could not possibly be in effect sooner than 2020. Its chance of success is probably less than 50%. I have spoken to the current maintainers of VS, gcc and clang, and have gotten informal agreement that they will not change their epoch of `system_clock`. This is in spite of Stephan Lavavej announcing otherwise here: http://www.youtube.com/watch?v=P32hvk8b13M&t=54m21s – Howard Hinnant Jan 16 '17 at 18:50
  • Thanks again. Now I also remember why I that I was worried about `system_clock` in the first place: I watched your follow up talk about your time zone library and there you repeated Stephan's announcement that VC plannes to change the epoch. I'm glad to hear that this no longer seems to be on the table. – MikeMB Jan 16 '17 at 20:24
  • Stephan was very gracious and reasonable when I approached him the day after that talk, in fact the entire VS library team was too. – Howard Hinnant Jan 16 '17 at 20:27
  • Keeping the epochs the same is indeed good news! I came here looking for an update on that comment during the talk and I'm glad to hear at least the unofficial outcome. – Brad Spencer Jun 09 '17 at 18:06
  • I've added a link to the C++20 `system_clock` epoch specification. – Howard Hinnant Mar 27 '20 at 15:51