Draft: WIP: Extend OWLTime/Date with conversions to/from std::chrono::time_point
@kolos , @avolio , we have never followed up on the idea of replacing OWLTime,OWLDate in future releases. Since it will require many changes in client code, we can't obviously do it in one go but have to be able to go there over time. I propose here a small addition to the owl/time.h header to ease any future transition.
This MR is marked WIP: as this is mostly for discussion, including if we ever want to do this at all. It's not meant for the next release.
This MR adds two methods to each OWLDate and OWLTime:
- A conversion operator to std::chrono::time_point<Clock,Duration>.
- A copy constructor that takes a std::chrono::time_point<Clock,Duration>.
The first method will make it easy for a client to use std::chrono types instead of OWLTime/Date when dealing with return values e.g. from IS objects:
std::chrono::system_clock::time_point t = is_object.time();
This allows any client code to prepare for a future interface change in advance.
The second method will handle the case where client code is not converted yet, but e.g. the ISInfo::time() method returns a std::chrono::time_point instead of OWLTime. This will allow old code to keep working. At this point the copy constructor in OWLTime/Date would have a [[deprecated("...")]] attribute and cause a warning in the client code, telling him what to do.
With enough warning for detectors, this could be kept for multiple releases, making it both possible to prepare in advance (1), and change the interface while old code keeps compiling (2).
The actual implementation is actually just converting counters internally.
Since std::chrono::time_point is not a fundamental type, there should be no accidental conversions happening.
The exact string formatting of OWLTime/OWLDate is obviously not available from time_point (which has parser functions from a stream, though), nor the reverse of taking a string in the exact format and turning it into an object. I don't know if anybody relies on this.