[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Kcal library time zone handling improvements
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2006-08-21 21:59:50
Message-ID: 200608212259.52431.lists () astrojar ! org ! uk
[Download RAW message or body]

On Monday 21 August 2006 21:11, David Jarvie wrote:
> On Monday 21 August 2006 18:31, Reinhold Kainhofer wrote:
> > Am Montag, 21. August 2006 16:56 schrieb David Jarvie:
> > > One facility which I propose to remove is to set the viewing time zone
> > > for a calendar. The idea of that facility is to automatically convert
> > > all fetched date/time values to the specified time zone (in the context
> > > of conversion from the UTC storage kludge). The problem with this is
> > > that once you have converted the time, you lose the original time zone
> > > information, and if you then update the calendar using the returned
> > > times, you will end up with different time zones than in the original.
> > > For some types of data this will be functionally different if daylight
> > > saving shifts occur differently in the two time zones. There is in any
> > > case no real need any more for automatic conversion to a viewing time
> > > zone, since it is easy to convert to whatever time zone you need using
> > > the KDateTime conversion methods (e.g. KDateTime::toZone(const
> > > KTimeZone&)).
> >
> > How efficient is this conversion? I mean, if you have a calendar with
> > hundreds of entries and all times in UTC and you are here in Austria,
> > each and every time you need a time (for displaying it in a string, for
> > an alarm, calculating the position of the event in the agenda, checking
> > if it happens on a given day, displaying a tool tip, etc.) the conversion
> > from UTC to the viewing time zone has to be done!

I see that you have already answered the question as to whether the same 
KDateTime instance needs to be converted to another time zone multiple times 
- evidently yes. I am posting a message on kde-core-devel about the best 
approach to take for caching converted values.

> > Are these conversions fast enough to be able to convert several thousands
> > of date/times (possibly even given in a foreign time zone) on the fly to
> > the viewing time zone?
> >
> > I know the recurrence class is already terrible in that regard (and the
> > bad implementation of the date matrix in korganizer even makes it worse,
> > so switching months already takes a significant part of a second...), so
> > the problems might sum up.
>
> These are very good points, which I'm afraid to say I hadn't thought of.
> There are two types of multiple conversion which can occur - the same
> instance multiple times, or multiple instances. Obviously the latter will
> occur, but is the former also a concern?
>
> Conversion of a KDateTime to UTC *is* efficient if done multiple times for
> the same instance, since the UTC value is cached. That also helps to speed
> up converting to another time zone, since the conversion is done via UTC.
> However, the resultant value in another time zone is not cached. For
> conversion of multiple KDateTime instances, each one is converted
> completely independently. Given the concerns you raise, it would be worth
> looking into ways of making conversions more efficient, perhaps by caching
> the value of the last time zone converted to (which would speed up
> repetitive conversions of the same instance to the same time zone), or by
> provision of a function to convert multiple instances in one go (which
> should allow a reduction of overheads and other efficiencies). I'll
> investigate this.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html
_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]