Bug#61611: Bug#48184: Solution

[GOTO Masanori]

At 28 Jul 2003 17:05:04 +0100,
Ian Redfern wrote:
> Now, TZDEFAULT is /etc/localtime, which is a symlink on a Debian system.
> Thus, when you call tzset() (or localtime(), which calls it) after
> changing the system timezone with tzconfig, it has absolutely no effect
> - it really should be looking at the name of the target of the symlink,
> not the name of the symlink itself.
> 
> The result of this is that changing the timezone effectively requires
> rebooting the machine to ensure all processes detect the change.
> 
> There is a way around it: if the code has something like the following
> in its inner loop:
> 
>         if (!getenv("TZ"))
>         {
>             putenv("TZ=GMT");
>             tzset();
>             putenv("TZ");
>         }
> 
> this will force the code to reevaluate the timezone file - twice. This
> is however CPU-inefficient and would require all programs on the system
> that deal with time (from syslog to Evolution) to jump through this
> hoop.

It can be used in the internal of applications.

> A better solution would be the following patch to tzset.c which checks
> /etc/localtime for modification each time it is called:

If we apply it, whenever we issue time related function, not only
time(2) but also lstat(2) is issued.  Filesystem related operation is
slow (imagine floppy root fs!).  Your request is very rare; most user
do not want such function performance drop.

> It adds a call to stat() to each call to localtime, but ensures that
> every program on the system changes when the timezone changes - quite
> invaluable to those of us who travel with laptops and irrelevant to
> anyone else. It can be switched off by setting the TZ variable
> explicitly.
> 
> If the GNOME clock people can put the inner loop patch at the start of
> clock.c:update_clock(), this would fix the problem for GNOME clock, but
> I would prefer to see libc6 fix it globally.

Yes, application modification is the easiest way.  And it make sense
when we imagine for example dynamic locale change.  It needs
application modification.


If you want to support dynamic timezone switch eagerly, I think one
way to improve is adding new environment variable (ex: TZ_UPDATE).  If
TZ_UPDATE is defined, then everytime tzset() checks timezone variable
through tzset() in each time.  However one major drawback is user
needs to set TZ_UPDATE environment variable before he wants to use
dynamic timezone switch and before he invokes applications.  So I
wonder it is really useful for most users.

Regards,
-- gotom