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

[Sebastian Trüg]

On Monday 19 March 2007 22:18:09 David Jarvie wrote:
> 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.

Sorry, but I have no idea what I need to do here. I am lost. This whole 
timezoning stuff it too much for me at the moment. For now I will just go 
back to my own conversion code and leave the time-only KDateTime for later.
I don't think that it is that big a problem since replacing it in KMetaData 
later on will not change anything, not the BC, not the API, and not the used 
data.

Cheers,
Sebastian