QTimeSpan: interest?
-
Hi,
Quite a while ago on the qt-interest mailinglist, a "question":http://lists.qt.nokia.com/pipermail/qt-interest/2010-June/024344.html on how to substract two dates in order to get a length of time inspired the creation of a class called QTimeSpan. It can be used to represent a period of time, where QDate, QTime and QDateTime only represent a single point in time. Now, the class is basically finished, and we've submitted it for inclusion in Qt.
On the "merge request":http://qt.gitorious.org/qt/qt/merge_requests/1014 a question was asked why this class would belong in Qt. Personally, I think it would fit nicely, but I am not the only user of Qt of course. That's where you come in. I think it would be beneficial if the associated "Jira ticket":http://bugreports.qt.nokia.com/browse/QTBUG-16556 would get some votes, to underline that more users than just the authors of this class think it would be useful to have in Qt.
If you'd like to have more information on the capabilities and design of the class before voting for its inclusion, please refer to the documentation that is available in the .cpp file in the merge request. I think it gives a nice overview of what's possible. Of course, I'd be willing to answer questions here too, and I would be interested in suggestions for further improvement. Note that the comments made in the merge request have already been fixed, but not committed yet.
André
-
Since you're there, how about a nice set of classes to handle datetimes and durations in a way that's really useful for the REAL world? :)
I.e. something
- that supports micro/nano seconds;
- that supports timezones and DST changes;
- that accounts for leap seconds;
- that accounts for working days;
- that supports arbitrary spans for months, days, hours, minutes, seconds and micro/nano second (and implement a reasonable logic for all of this);
etc? :-)
-
@peppe:
QTimeSpan actually does support timezones, at least in so far QDateTime supports it. :-)
DST changes is actually a good point. We did not considder this, and we should test what happens. I don't know if it would be possible to take into account, I guess it depends if QDateTime already does this or not. A problem may be that DST's rules tend to change now and then...The support for arbitrary spans is currently quite extensive, I'd say. QTimeSpan can represent (in theory) anything from 1 ms to roughly 292 million years. I doubt if it makes sense to use it for such long time periods (at 1 ms precision), but don't let me stop you :-) That does make me think though: we should probably test what happens at really long time periods that would move out of QDate's range. Currently, that is not something that we covered in the unit tests.
While we're at it: is there a reason to stop at nano seconds? A zeptosecond or yoctosecond could also be useful perhaps? ;-)
-
With DST (and respectivly 23/25 h days) QDateTiem has a problem, and afaik it's not fixed up to now.
You do not get out of QDateTime it its the first 2 o'clock in the morning or the second one :-( (DST in Germany happens at 3 o'clock with a switch back to 2 o'clock, so you have 2 o'clock two times that day).
Same applies to the QDateTimeEdit, there you don't know, which of the two you set by setting 2:30 ...
-
Nice class. Voted for it.
-
@Gerolf:
So, the problem is, that 02:30 on the date the clock goes back an hour is simply an ambigous time. I am not sure there is anything you can do about that, other than specifying the time in UTC instead. There are "bugreports":http://bugreports.qt.nokia.com/browse/QTBUG-10219 in Jira to ask for a better support for timezones in QDateTime. -
Great work. I voted for it because I needed this a while ago, and for sure I will need it in the future.
-
A timespan has some pitfalls:
If it uses walltime as the two reference points, you must handle cases where start time is actually after end time. This is because there system time can be updated from a time source (and might jump back in time). IIRC on cell phones this happens quite often, but it can also happen if your desktop system is connected to a NTP time source. It can also happen if you are not connected to a external time source, for instance due to DST changes.
This is also mentioned in the documentation for QTime::elapsed(), which is often used for the same purpose. (actually it says that the result is undefined) -
voted too
-
I need this class, seems to be very useful!!!
-
Hello Andre,
I think QTimeSpan class is really a missing part of the Qt Project. Thanks for yours and Sean's efforts!
I have a question regarding the legality. Is it possible to use your sources in a commercial project (we use Qt with LGPL) as a part of a code-base (do not incorporate it to the Qt libs) before it becomes a part of Qt officially?
Thanks!UPD: English has been slightly improved.