Hi, On Thursday 25 August 2011 08:56:30 [email protected] wrote: > On 8/24/11 7:06 PM, "ext John Layt" <[email protected]> wrote: > The whole QTimeSpan piece makes me wonder. QTimeSpan is bound to the > gregorian calendar currently. It feels odd introducing this class with > that limitation.
For any units greater than a day yes (or maybe a week but I do not know if all calendar systems agree upon what a week is or if they even have that concept at all). So yes we should make use of the calendar support for these larger units of time where it makes sense to do so. > Exactly the reason I once commented on the merge request that I don't like > the TimeUnit enum in the Qt namespace. The enum values are too generic to > not likely clash with something else at some point. ACK. > >I should probably start a spearate thread for this, but do you see the > >need for a separate QDuration in addition to QTimeSpan? By that I mean a > >very lightweight class that has no knowledge of date or timezone or > >absolutestart point, just stores H:M:S.ms, sort of like a QTime compared to > >QDateTime. I was thinking about this the other day too. At present QTimeSpan contains a QDateTime for the optional reference and a qint64 for the number of milliseconds. This makes it the temporal analogue to an imaginary class used to represent the 1-dimensional position and length of a physical object. Thinking about it this way I can see value in introducing a QTimeDuration class to represent only the length of time (cf. how a qint64 could be used to represent a physical length in mm say). This QTimeDuration should only support units that are of standard fixed size (ie days, hours, minutes, seconds and msecs - assuming that is the precision agreed upon). The internal storage could still be a qint64 of course. QTimeDuration should support the usual arithmetic operations. QTimeSpan could then be refactored to use a QDateTime and a QTimeDuration instead of a naked qint64. The additional facilities that QTimeSpan would bring to the picture would be those associated with having a reference point (e.g. intersection testing, union) and support for the longer variable units of time (months, years) in conjunction with the calendar system being discussed. With the help of the calendar system I think QTimeSpan could then also offer support for arithmetic using the variable-length time units. ie Add 1 calendar month. Cheers, Sean _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
