Hi, I've completed the first set of changes to improve QDateTime. These are the minimum changes required for 5.0 to clean up QDateTime and allow future changes to the implementation during Qt5 without breaking Binary Compatability.
You can find the changes at https://qt.gitorious.org/~odysseus/qt/odysseus- qtbase/commits/qt5-qdatetime . If anyone interested could have a look and make suggestions, then I'll raise a merge request in the near future. The changes made are: * Remove Symbian and WinCE support * Remove obsolete methods and apidox * Merge duplicate methods * Change inline methods to normal methods * Add Private classes to QDate and QTime * Change QDate from uint32 to int32 to extend date range before 2 Jan 4713 BC * Change definition of isValid() * Add validity checks on input values The two main discussion points are the date range and how it affects the definition of isValid(). Using an int32 gives a range of +/- 5.8 million years which should be good for most uses and doesn't increase memory usage, but doesn't cover much of Geological Time (4.5 billion years ago) or Astronomical Time (13.75 billion years ago). For that we would need an int64, but that seems wasteful for most use cases, especially on memory-challenged platforms. The definition of isValid() is now that the date falls inside the range supported by the calendar formulas for correctly converting the jd into a ymd format, so for the current formulas 4800 BC to 1,400,000 AD. These changes are obviously Binary Incompatible but so far still Source Compatible. The next step however isn't Source Compatible so I want to get some review of the APi design before I go any further. The next step is improving the date/time formatting and adding calendar system support which is closely related. The current formatting api is spread over QLocale and QDateTime but is inconsistent between the two and rather incomplete. I want to merge these and make them fully conform to the Unicode CLDR format standard options to allow for full native platform compatible support. The Source Incompatible changes shouldn't be noticed by most apps as they mostly affect the QLocale api that provides the formats and translations used by the formatter. Most apps just call the standard QDate toString() and fromString() methods in a way that shouldn't be affected by the proposed changes. You can find the new API proposals documented at http://community.kde.org/KDE_Core/QtMerge/QDateTime One other question, currently the QDate, QTime, QDateTime and QDateTimeParser classes are all in a single header and source file. Should I break them out into separate files? When I add the new private QCalendarSystem and QDateTimeFormatter classes should they also go in the same file or separate? Cheers! John. P.S. For those interested in time zones, I've been talking to people at the Desktop Summit about the design and I'll try to get something posted to the list in the next few weeks. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
