Caching local time zone

[David Jarvie]

On Saturday 23 September 2006 12:18, Shaheed wrote:
> On Friday 22 September 2006 00:05, David Jarvie wrote:
> > >> What should happen during startup if an application requests time zone
> > >> information before the kded module has run?
> > >
> > >How about an environment variable? If that made sense, it might be
> > > possible to combine that with this idea for per-user TZ settings in
> > > KDE:
> > >
> > >http://lists.kde.org/?l=kde-pim&m=112379368522252&w=2
> >
> > Your proposal for per-user TZ settings sounds a good idea to me. But when
> > an application asks for the local time zone, it is likely to be in the
> > context of wanting to convert a date/time value to or from that zone. So
> > even if the zone identity is readily available, it will still need all
> > the KSystemTimeZones initialisation to run at that point. So the question
> > remains as to what should happen if the request is made before the kded
> > module runs.
>
> I guess I was not very clear. Let me try again...
>
> 1. As expected, startkde does a whole lot of stuff, including invoking the
> various user scripts in <localprefix>/env/*.sh and <prefixes>/env/*.sh
> *before* kdeinit runs.
>
> 2. Thus, this is a resonable place for the per-user TZ setting as per the
> mailing list entry above.

I agree.

> 3. Now, let's assume the script fragement that sets the TZ in "filename
> format" such as "Europe/Paris" also does the lookup of the full timezone
> info: the returned info could be cached in an updated TZ using
> the "specification format" rather than the "filename format"
>
> I think that all apps which access the local timezone would be guaranteed
> to hit the fastpath of finding the information needed in the TZ env. var.
> rather than any significant filesystem activity.
>
> Does that sound right?

I was actually saying that the full KSystemTimeZones initialisation needs to 
be done before any applications ask for time zone information. Not just for 
the single time zone that the user wants as the default, but also the scan to 
determine the full list of time zones done in 
KSystemTimeZonesPrivate::findZoneTab() and 
KSystemTimeZonesPrivate::readZoneTab(). (Only some systems need lots of file 
activity for this - if zone.tab exists, these methods just read it.) And, 
until individual user time zones are implemented, or if the user hasn't 
specified his/her own time zone, all the processing in 
KSystemTimeZones::local() to determine the local system time zone needs to be 
done. (Again, the processing required varies enormously from system to 
system.)

In fact local() probably should be called in any case since the system clock 
still exists and if any _system_ local times need to be processed, the system 
time zone needs to be known. Only if _all_ calls to fetch the local time were 
made through KDateTime (and not through QDateTime or time()) could it be 
guaranteed that the user's individual time zone was being used, and finding 
out the system time zone could be dispensed with. But that's too much to 
assume.

I think that caching zone.tab information (where the actual zone.tab file is 
missing), plus MD5 checksums for finding the local system time zone (where 
necessary), could be done in a global config file (as Lubos suggested). Then 
much of the initialisation processing could be avoided altogether since the 
config file could persist from session to session.
 
-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html