Link: https://wiki.qt.io/QtCS2018_Date_Time
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 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
