Caching local time zone
lists at astrojar.org.uk
Sat Sep 23 16:57:58 BST 2006
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.
> 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::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
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
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.
KAlarm author and maintainer.
More information about the kde-core-devel