[Development] QTimeScheme for Qt - 5.0 or 5.1?

lorn.potter at nokia.com lorn.potter at nokia.com
Fri Jan 27 00:11:27 CET 2012


There is also this one:
https://bugreports.qt-project.org/browse/QTBUG-71

I had working code (for 4.6), but lacked time to fix a few bugs and such. I started with the QTimeZone class in Qtopia. It did use the timezone database.
I also had a windows<>Olsen conversion for all platforms.


From: ext Stephen Kelly <stephen.kelly at kdab.com<mailto:stephen.kelly at kdab.com>>
Date: Thu, 26 Jan 2012 23:43:45 +0100
To: <development at qt-project.org<mailto:development at qt-project.org>>
Subject: [Development] QTimeScheme for Qt - 5.0 or 5.1?




Hi there,



In looking at what it would take to add time zone support to Qt 5:



https://bugreports.qt-project.org/browse/QTBUG-23509



I'm following the python API which provides the same thing.



To investigate whether this could go into Qt 5.0 or not (ie, what is the impact on QDateTime), I started a patch:



http://codereview.qt-project.org/14405



In the patch I worked on the assumption that source compatibility does not matter. Of course it does, but it helps to see where compromise is needed.



Some of the API, eg 'void setUtcOffset(int seconds);' could be implemented by creating a new QTimeScheme properly configured with a UTC offset, but I took it out anyway rather than attempting to show a port in the patch.



It might also make sense to use QSharedPointer<QTimeScheme> in the APIs.



What I would mostly like to get feedback on though is the impact on the QDateTime API and behaviour, and how it is put through QDataStream etc. I'm not sure if there is any particular way (historical) timezone information should be transmitted over the wire (if at all).



If it should not be handled at all in some cases of streaming a QDateTime, but it should be handled in others (which I think is the case - we don't want to lose this information in most cases), the to-be-streamed QDateTime would have to have its timezone information stripped in the former case.



That would be a source incompatible change if it happened in Qt 5.1. I'm also unsure about mapping cleanly from the Qt::TimeSpec enum to some class like QTimeScheme (I named it that instead of QTimeZone because utc offsets are not time zones).



I think something like this abstraction should go into Qt 5.0, but I would like to get other opinions too. Do you think something like this can be added in 5.1 just as well?



Thanks,



--

Stephen Kelly <stephen.kelly at kdab.com<mailto:stephen.kelly at kdab.com>> | Software Engineer

KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company

www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090

KDAB - Qt Experts - Platform-Independent Software Solutions

_______________________________________________ Development mailing list Development at qt-project.org<mailto:Development at qt-project.org> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120126/4280d9f4/attachment.html>


More information about the Development mailing list