< KDE Core | QtMerge Contents 1 QTimeZone 1.1 ICU 1.2 Qt Proposals 1.3 Mac OS X 1.4 Windows 1.5 KTimeZone & KDateTime QTimeZone See QtCS discussions at http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/QDateTime ICU Qt5 locale will move to depending on ICU for localisation backend. ICU implements timezone support so any solution must well with this. ICU ships a version of Olsen which can be outdated and different from the system, but can be updated. It also gives each zone a canonical id, and provides full translations. It also provides mappings to Windows tz names in ICU 4.4 and later. Should be the default fallback implementation, with host system version used if available. References: http://userguide.icu-project.org/datetime/timezone http://userguide.icu-project.org/datetime/timezone/examples http://icu-project.org/apiref/icu4c/classTimeZone.html ICU does have a nasty API for most things, but that's what Qt is for :-) Qt Proposals Steve has made a proposal based on Python. http://lists.qt-project.org/pipermail/development/2012-January/001628.html http://codereview.qt-project.org/#change,14405 http://icu-project.org/apiref/icu4c/classTimeZone.html Lorn Potter has previously proposed patches based on Meego: https://bugreports.qt-project.org/browse/QTBUG-71 Mac OS X Mac API: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DatesAndTimes/DatesAndTimes.html#//apple_ref/doc/uid/10000039i https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DatesAndTimes/Articles/dtTimeZones.html#//apple_ref/doc/uid/20000185-BBCBDGID https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimeZone_Class/Reference/Reference.html Need to investigate if Mac uses ICU time zones or system file? Windows http://msdn.microsoft.com/en-us/library/windows/desktop/ms724962%28v=vs.85%29.aspx KTimeZone & KDateTime http://api.kde.org/4.4-api/kdelibs-apidocs/kdecore/html/classKTimeZone.html KDateTime obtains the current system time zone from KSystemTimeZones::local(), which in turn requires the ktimezoned daemon to update it with any changes to the current system time zone. This would prevent KDateTime from being moved into Qt without modification to this mechanism. Additionally, Qt would need to support Mac OSX and any other operating systems - currently, KSystemTimeZones is only supported on Linux and Windows. Note that all the KTimeZone classes would need to be moved to Qt also in order for KDateTime to work. If KDateTime were merged into QDateTime, it would probably require source incompatible changes to create a nice API for the combined class. A better way of merging KDateTime into Qt4 would be to add a new class alongside QDateTime. QDateTime would be kept as a simple class without any time spec (source incompatible change), alongside the merged KDateTime to be used when any time spec was needed. It wouldn't be a good idea to keep QDateTime unchanged in this scenario, since the current QDateTime's time spec property wouldn't play along very nicely with the new KDateTime class's more sophisticated time spec property - having both would lead to unnecessary confusion. http://bugreports.qt.nokia.com/browse/QTBUG-10219 http://bugreports.qt.nokia.com/browse/QTBUG-71 http://bugreports.qt.nokia.com/browse/QTMOBILITY-1139 Retrieved from "https://community.kde.org/index.php?title=KDE_Core/QtMerge/QTimeZone&oldid=17895" This page was last edited on 12 February 2012, at 13:03. Content is available under Creative Commons License SA 4.0 unless otherwise noted.