Bug#61611: Bug#48184: Solution

[Bruce Allen]

I filed a glibc bug report about this many months ago, and the maintainer
fixed it recently.  Check glibc buzilla (I think that the home is at
redhat these days) to confirm.

Cheers,
	Bruce

On Fri, 22 Oct 2004, GOTO Masanori wrote:

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