Caching local time zone
David Jarvie
lists at astrojar.org.uk
Sat Sep 23 17:55:15 BST 2006
On Saturday 23 September 2006 12:29, Lubos Lunak wrote:
> Dne čtvrtek 21 září 2006 16:55 David Jarvie napsal(a):
> > The amount of I/O needed by KTimeZones
> > depends on the system. In the best case, where a zone.tab file exists and
> > the local system time zone is available from the TZ environment variable,
> > there should only be a couple of files opened. In the worst case (e.g.
> > Solaris), all the files in the zoneinfo directory are read at
> > initialisation, and if there is no TZ environment variable or
> > /etc/localtime link, finding the local time zone (the first time only)
> > can also result in reading a lot of zoneinfo files.
>
> On SUSE 10.1 I have no TZ and /etc/localtime seems to be a hardlink, so
> that doesn't help with finding the timezone either (and, with TZ, I wonder,
> how do you change that if you change the timezone - or will that be
> forbidden while KDE is running?).
A good point - presumably TZ won't any longer reflect the system time zone if
it's changed after KDE (or any other process) has started up. If that's true,
many processes (KDE and non-KDE) would fail to determine the new time zone
since using TZ is the standard glibc way of accessing it. So changing time
zone might really require a reboot to be certain that everything has
recognised the change. Or is this supposition too far-fetched?
> > (Looking at the code, it's
> > possible that the same files might be read twice - at initialisation and
> > when finding the local time zone. I'll investigate that.)
>
> Twice is not really the problem, the second one is cached. The problem is
> that the first one is not.
The second one won't necessarily be cached when hundreds of files need to be
reread.
--
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html
More information about the kde-core-devel
mailing list