PATCH: time-only support for KDateTime (used in Nepomuk-KDE)

[David Jarvie]

On Monday 19 March 2007 19:21:28 Sebastian Trüg wrote:
> On Friday 16 March 2007 13:51:16 David Jarvie wrote:
> > On Friday 16 March 2007 10:52, Sebastian Trüg wrote:
> > > On Thursday 15 March 2007 14:12:40 David Jarvie wrote:
> > >> In KDateTimePrivate::setTimeOnly(), mDt should be set using setDt() to
> > >> ensure that 'ut' and caching members are updated properly.
> > >
> > > done.
> >
> > Sorry - I didn't think sufficiently before writing the above comment. You
> > should really try to preserve any valid caching that's been done already
> > on the value. So you need to take account of whether it's a UTC value or
> > what time zone it is, etc. A simple call to setDt() wipes out anything
> > already cached, while setting mDt directly may or may not invalidate the
> > cache. Plus, you need to take account for a TimeZone instance what date
> > is being used as the basis for evaluating the UTC offset. That could make
> > things altogether more complicated. Also remember that QDateTime in Qt 4
> > has an important third parameter - don't use the default without being
> > sure it's appropriate.
>
> Well, I think I will have to look into that timezone issue properly again.
> I had hoped that this could be a quick fix... ;)

Unfortunately, handling time zones properly isn't straightforward. It's 
important to cache time zone conversions (when a TimeZone type is involved), 
since some applications in kdepim can create thousands of instances of 
KDateTime and may call for the same conversion multiple times for each. 
Ensure that both you consider both the UTC and time zone cache values to see 
whether either or both should be invalidated whenever mDt is updated. It's 
also important to think for every QDateTime, is it Qt::LocalTime or Qt::UTC?, 
since that makes a difference when the QDateTime is used in KDateTime 
functions, even in mDt in the d-pointer class. Basically, you need to think 
for each line of code you write, what time spec am I dealing with here?, and 
consider each possible KDateTime::SpecType value.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm