QtCS2018 Date Time: Difference between revisions
Jump to navigation
Jump to search
(Created page with "Howard Hinnant's new civil calendar and timezone proposals have made it to the C++ 20 draft (N4750) * Not implemented yet in any C++ Standard Library === Time Zone === * Why...") |
(No difference)
|
Revision as of 12:58, 11 June 2018
Howard Hinnant's new civil calendar and timezone proposals have made it to the C++ 20 draft (N4750)
- Not implemented yet in any C++ Standard Library
Time Zone
- Why would we use this, if we have to keep our existing code?
- Allows us to hook to a standard tzdb implementation without forcing an ICU dependency
- Good for Windows (MS doesn't want us to use the registry DB anyway)
- Good for iOS (no need for Apple's ICU-wrapper API)
- Can it be used without exceptions?
- We should add a backend for it when we can
- Drop unneeded backends
Front-end API
- What do we do for QDate and QTime?
- We should add conversion API for the new types as soon as we can
- QT_HAS_INCLUDE(<chrono>), like QDeadlineTimer does for std::chrono::duration and std::chrono::time_point
- Is there anything missing in C++20 draft which would prevent a QDateTime refactor in the 2020s?
- (Keeping QDateTime convenience API but replace the QDateTimePrivate backend)
- Eddy is working with Howard to make sure everything is there
- Compilers don't have this yet, but should have it in 2019 or early 2020
- But we don't think we can reimplement QDateTime using date.h for Qt 6
- Too close to call, regarding BC guarantees
- Review QDateTime API:
- Anything we want to deprecate anyway?
- Anything that would be difficult to implement with date.h and we'd want to provide different API for?
Calendar systems
- Didn't have enough time to discuss this
- We have a contribution for QAbstractCalendar
- We need a solution that enables code outside of Qt to implement their own calendars