Bug 172396

Description of problem:

This program should print out 2 different timestamps :
---
#!/usr/bin/perl
use POSIX ;
$t = time();
$ENV{'TZ'}="US/Eastern";
$east = scalar( localtime( $t ));
$ENV{'TZ'}="US/Western";
$west = scalar( localtime( $t ));
print $east,"\n", $west,"\n";
---

But it does not: 
$ ./tz.pl
Thu Nov  3 13:54:04 2005
Thu Nov  3 13:54:04 2005

This is because when PERL is compiled with multi-threading enabled, it uses 
localtime_r, which does not call 'tzset', contrary to the documentation
of localtime(3), which does call 'tzset'. 

This is an upstream perl bug :
26136: localtime(3) calls tzset(3), but localtime_r(3) may not. 
      ( http://rt.perl.org/rt3/Ticket/Display.html?id=26136 )

-- Additional comment from tao on 2005-06-22 05:22 EST --
From User-Agent: XML-RPC

Analyzed the problem and tracked down its cause and also got a workaround.
(Thanks go to Bill Nottingham and Jakub Jelinek for help on this). To get
the original (pre-perl-5.8), you should declare "use POSIX qw(tzset);" at
the start of your script (with other use clauses) and instead of calling
"localtime" call "tzset; localtime" or after each $ENV{TZ} = assignment
call tzset; this should make the script behave as expected. We'll try and
consult perl upstream about this behaviour in the meantime and if the
proposed workaround is not good enough, we'll see if this can be corrected
in the perl package itself.

--- Additional comment from Issue Tracker (tao) on 2005-06-22 05:22 EST

Actually, Pete Rockai found the solution; basically, glibc caches

the timezone. Given their example script, what they need to do is

do an explicit tzset() after setting the environment variable.

i.e.:
/usr/bin/perl -e 'use POSIX qw(tzset); my $t = time; print "$t ", scalar
localtime($t), "\n"; $ENV{TZ} = "Japan"; tzset; my $t = time; print
"$t ", scalar localtime($t), "\n";'

The reason this changed between perl-5.6.x and perl-5.8 is
probably because perl switched to using localtime_r (the thread-safe
version), which doesn't reset the timezone automatically.

What we'd recommend is that they fix their code to explicitly
set the timezone; we can see about having upstream perl change
its behavior to automatically do the tzset on calls to localtime(),
but we don't want to break compatibility with upstream by either
doing it ourselves, or switching perl back to using localtime
instead of localtime_r.

Bill

-- Additional comment from jvdias on 2005-11-02 22:50 EST --
A fix for this issue has been developed, and appended as a patch to the
upstream perl bug that was raised on this issue :
26136: localtime(3) calls tzset(3), but localtime_r(3) may not. 
      ( http://rt.perl.org/rt3/Ticket/Display.html?id=26136 )

If the upstream PERL developers agree to accept this patch, then I will
submit it to our PERL distribution.

The patch detects this problem during the Configure phase, and if it was
detected, and perl is being built multi-threaded (localtime_r is used),
will insert a tzset call before any localtime_r call .

The downside of this fix is that glibc uses mutex locking in the tzset call, 
so there would be a performance hit and multi-threaded perl programs would 
experience synchronisation around their localtime calls ( thankfully, 
genuinely multi-threaded perl programs are few and far between, and no 
other impact other than a performance hit would result from this fix ).

-- Additional comment from jvdias on 2005-11-03 13:47 EST --
OK, I've had some positive feedback on the patch from the perl5-porters mailing
list, but as yet, no response from the perl upstream maintainers.
I'm going to submit the patch to FC-5's perl-5.8.7 release, and if all goes
well, and the upstream maintainers do accept it, I'll apply it to a future
RHEL-4 release ( probably not U3 at this late stage ).