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?

- 12,403
- 6
- 52
- 73
-
3`epoch` in general represents the starting point of a clock. There is more than one clock in `c++11 chrono`. – bolov Apr 22 '15 at 13:42
-
http://en.cppreference.com/w/cpp/chrono/time_point/time_since_epoch – SChepurin Apr 22 '15 at 13:59
-
1This article explains this: http://www.informit.com/articles/article.aspx?p=1881386&seqNum=2 – newbie Apr 22 '15 at 14:13
1 Answers
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 betweensys_time
and calendar types (27.8). [Example:sys_seconds{sys_days{1970y/January/1}}.time_since_epoch()
is0s
.sys_seconds{sys_days{2000y/January/1}}.time_since_epoch()
is946’684’800s
, which is10’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_point
s 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_point
s 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 typesys_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 betweensys_time
and calendar types ([time.cal]). [ Example:sys_seconds{sys_days{1970y/January/1}}.time_since_epoch()
is0s
.sys_seconds{sys_days{2000y/January/1}}.time_since_epoch()
is946'684'800s
, which is10'957 * 86'400s
. — end example ]

- 206,506
- 52
- 449
- 577
-
1For 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
-
1Here 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
-
5Nothing 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