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 ).
This bug is fixed in perl-5.8.7-0.7.fc5 .
assigning to rnorwood