Caching local time zone

[Shaheed]

On Saturday 23 September 2006 16:57, David Jarvie wrote:

> 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.)

Ack.

> 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.)

Ack.

> 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.

This makes sense.

> 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.

Ack.

> 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.

Again, yes. Maybe then, instead of the TZ setting via one of the script 
fragments, it should also be set via the same config file. Then, if someone 
ever wrote a kcm module to set the user's TZ, this is all centralised?

Thanks, Shaheed