KDateTime value caching approach

[David Jarvie]

In kdepim, as Reinhold Kainhofer has pointed out, applications frequently have 
to store thousands of date/time values and to convert them on the fly to the 
viewing time zone, often multiple times. Time zone conversions 
(pre-KDateTime) already cause noticeable delays in some circumstances, and 
there is a need to make them more efficient in KDateTime. I think that 
KDateTime instances therefore need to cache not just their UTC equivalents as 
now, but also converted values in other time zones. I can think of 3 
approaches to take:

- Cache all converted values in a QList, each element of which would contain a 
QDateTime and a KTimeZone pointer. To save space, the instance would only 
contain a pointer to the QList, the QList being created only when needed.

- Cache just the last converted value. Then, if the instance was converted to 
another time zone, the previous conversion would be lost and would have to be 
recalculated if needed again.

- Allow the application to set a configurable class-wide limit to the number 
of different time zones whose converted values will be cached. Then, if the 
application set the limit to 2 and the KDateTime was converted to 
Europe/Vienna and afterwards to Pacific/Kiritimati, the Europe/Vienna value 
would still be in cache for subsequent reuse. For this purpose, a QStack 
might be best, since it allows the latest conversion to easily be stored at 
the head of the list, thereby automatically discarding the oldest conversion 
if the limit is exceeded.

There is obviously a trade-off of perfomance in return for memory usage, and 
the first option could in the worst case use up a very large amount of 
storage if values were converted to many different time zones. Since I'm not 
sure what range of requirements applications will have, I'm not sure about 
the best approach. Opinions would be welcomed, particularly if they are based 
on real-world requirements.

-- 
David Jarvie.