Date/Time in KF5 / Qt5

[David Jarvie]

On Wednesday 06 July 2011 22:25:05 Sean Harmer wrote:
> On 06/07/2011 21:18, David Jarvie wrote:
> > On Wednesday 06 July 2011 21:10:06 Thiago Macieira wrote:
> >> Em Wednesday, 6 de July de 2011, às 20:54:54, David Jarvie escreveu:
> >>>> Duration is simply the number of seconds or milliseconds between two
> >>>> dates,  appropriately given in their universal time. So duration is not
> >>>> affected by daylight savings.
> >>> Duration must record whether it was specified in terms of
> >>> hours/minutes/seconds, or days/weeks/whatever so that daylight savings
> >>> changes can be taken into account when calculating the end time of a
> >>> duration, given a start time.
> >>>
> >>> If the duration class provides methods to calculate the end time, given a
> >>> start time, then it must take account of daylight savings changes.
> >>>
> >>> See kdepimlibs/kcalcore/duration.h for example.
> >> That's not what QTimeSpan is supposed to be. It's simply a quantity of
> >> seconds.
> > Ok. Being more limited, it won't be a suitable replacement for KCalCore::Duration.
> I would need to take a closer look at KCalCore::Duration but from what 
> you have said it should be very simple to implement an equivalent to it 
> in terms of QTimeSpan given that a duration is a fixed quantity (within 
> an inertial frame). QTimeSpan has the facility to specify a start 
> datetime and to calculate the end of the span but where it would fall 
> short is the representation of that end time if it lies in a period of 
> daylight savings different to the start time.
> 
> QDateTime simply stores a QDateTime as the optional start (or end time 
> if the span is negative) and the duration in milliseconds as a qint64. 
> It was meant as a simple convenience class for cases like displaying a 
> label with "Download has x:y remaining" or for working with datetime 
> mathematical operations analogous to QRect for e.g.

I've added a comment to the merge request suggesting that instead of a reference date/time, the units in which the time span was specified should be stored in the class. That way, daylight time changes could be catered for easily (by external classes), and also time spans of months or years would work intuitively when applied to any start date. Basically, I think that the class has taken the wrong approach, and could be made much more generally useful with a simple change in the way it does things.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110706/ab8740b7/attachment.sig>