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.
All the best,
Sean
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
