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
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:
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.
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.
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.
@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.