Why exactly should I prefer std::chrono over ctime for time and date?

I have been using the <ctime >header for quite some time now and it's been serving me well, no complaints.
But someone told me that this header is old, and that I should be using std::chrono for time and fate in C++ because it's a modern way to do so and it's better.
I went googling around and found out how it is used but to be honest I found it too verbose and not as very straight forward as the functions in <ctime>, the same with Howard Hinnant date library https://github.com/HowardHinnant/date

Even though <ctime> is not type safe, I find it much more simple and straight to the point than <chrono>.

Why should I use <chrono> and when I do use it how can I get these informations in chrono like I get in <ctime>:

1
2
3
4
5
6
7
8
int tm_sec 	
int tm_min 	
int tm_hour 	
int tm_mday 	
int tm_mon 	
int tm_year
int tm_wday
int tm_yday 	


Last edited on
@Furry Guy I had seen that question.

I am guessing I haven't yet come across the need to use the chrono functions.
But with current needs how can I get the tm_sec, tm_min, , tm_hour etc equivalent, in chrono.
Yes... but it shouldn’t.

The problem is that the ISO C++ committee is having something of an all-out war over date-time handling, with no likely solution in sight. Hinnant’s library is the nicest thing out there so far, but some members hate it.

While ancient and stable, C’s date and time handling library has significant issues as well. You mentioned one of them:

  • Not type safe
  • Not thread safe

Chrono is — and always has been — just a thin wrapper over that stuff. It was never meant to replace it.

Consequently, if you are more comfortable with using C’s date-time stuff directly, then do so.

Hopefully some day we will see sane date-time handling in C++. But for now, you can set things up fairly nicely anyway:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <chrono>
#include <ctime>
#include <iostream>

namespace chrono = std::chrono;
using namespace std::chrono_literals;

template <typename Clock, typename Duration>
std::ostream& operator << ( std::ostream& outs, const std::chrono::time_point <Clock, Duration> & dt )
{
  char s[200];
  auto t = Clock::to_time_t( dt );
  std::strftime( s, sizeof(s), "%c", std::localtime( &t ) );
  return outs << s;
}

int main()
{
  auto today = chrono::system_clock::now();
  std::cout << "Today is " << today << "\n";
  
  auto tomorrow = today + 24h;
  std::cout << "Tomorrow is " << tomorrow << "\n";
  
  auto day_after = today + 24h * 2;
  std::cout << "The day after that is " << day_after << "\n";
}

Lines 19, 22, and 25 are really the ultimate goal: easy user code.

Sorry I can’t tell you any better.
Thanks for the code @Duthomhas, and your explanation really simplified the things for me.
chrono is incredibly safer, far more capable and measurably faster than all other date-time libraries it competed with, including of course ctime APIs or any wrappers of that.

However, the question "how can I get the tm_sec ... equivalent" makes no sense to me because tm_sec is meaningless on its own. https://en.cppreference.com/w/cpp/chrono has an overview of the C++ types, if that helps.
Last edited on
I would think of chrono as an addition. ctime and chrono have different focuses.

ctime is more for representing particularly strftime(...).

chrono is more for calculating.

So both have their use.
@Cubbi, ok maybe the question is made wrong so reformulating the question: how do I get the system second, minute, hour, day of week, day of month, year in chrono?
You have the right idea, preferring C++ over C when C++ has the same or similar functionality. Sadly ATM with <chrono> that isn't the case.

The <chrono> library only deals with time and not dates, except for the system_clock which has the ability to convert its timepoints to time_t. So using <chrono> for dates will not improve things much.

https://stackoverflow.com/questions/17223096/outputting-date-and-time-in-c-using-stdchrono

Until the ISO C++ Committee decides otherwise, and as Duthomhas pointed out that isn't likely to happen anytime soon, <chrono> won't have any mandated standard for dealing with dates. <ctime> for the foreseeable future is still needed when dealing with dates. Despite its limitations of not being type or thread safe.

Boost has a Date-Time component that might be worth a look. More than a few Boost components became ISO C++ standard components. Maybe Date-Time will be what is accepted as the standard when the in-fighting stops.
https://www.boost.org/doc/libs/1_72_0/doc/html/date_time.html
https://www.boost.org/doc/libs/1_72_0/doc/html/date_time/examples/general_usage_examples.html
<chrono> won't have any mandated standard for dealing with dates.

That already happened. chrono in C++20 supports dates. See https://en.cppreference.com/w/cpp/chrono for a summary (or the working draft)

how do I get the system second, minute, hour, day of week, day of month, year in chrono?

If by "system" you mean local time in the current time zone, there's an example at https://github.com/HowardHinnant/date/wiki/Examples-and-Recipes#converting-to-a-tm (this uses the library that inspired the standard, but until it's implemented in all compilers, the library is the way to go)



Last edited on
@Cubbi, it would help if you hadn't quoted half of what I said. I specifically said "Until the ISO C++ Committee decides otherwise....."

Now, as to my ignorance about C++20 having Date support, that is my error. I am not as knowledgeable about the proposed standards as I probably should be. Not that this is an excuse, but the compilers I use are hit and miss regarding not yet standardized C++20 support. MSVC and Modules, for instance. I can't even successfully compile anything using custom written modules. I tried repeatedly with each update to the IDE.

I don't know all the ins-and-outs of what C++ in general can do, no matter what the standard is. The price of being self-taught as well as a dilettante hobbyist. C++17 is still much of a murky mystery for me.
Last edited on
Oh, and thanks Cubbi for mentioning the Howard Hinnant library inspired the proposed standard. I will have to take a peek at it and the usage to get a heads-up on the possible usage syntax.
@Cubbi and @Furry Guy thanks for the links, that really helped and your explanations really said what is to be said about <chrono> vs <ctime> I need to know in my case.

I will stick with <ctime> for now as my application is really simple and does not have to be type safe or thread safe.

Going over the <chrono> and Hinnant library and examples I could see how important they are going to be for my future applications and I am on the watch out for what C++20 is bringing in this regard.

Topic archived. No new replies allowed.