PHP 4.0 Bug #4732 Updated: timezone woes
| From: | sniper@php.net | Date: | Tue, 09 Jan 2001 09:06:47 +0000 |
| Subject: | PHP 4.0 Bug #4732 Updated: timezone woes | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-43523@lists.php.net to get a copy of this message | ||
ID: 4732
Updated by: sniper
Reported By: ej@code-energy.com
Status: Closed
Old-Bug Type: Misbehaving function
Bug Type: *General Issues
Assigned To:
Comments:
Fixed in CVS.
--Jani
Previous Comments:
---------------------------------------------------------------------------
[2000-07-02 05:10:17] sterling@cvs.php.net
This is fixed in PHP4.0.1
---------------------------------------------------------------------------
[2000-05-31 17:43:28] ej@code-energy.com
Bug #3977 refers to this problem as well (can use that script for bug producibility).
I've tracked this down to a difference between "localtime" and
"localtime_r"
(and probably most of the reentrant functions). The following excerpt from glibc-2.1.3/time/tzset.c
578 /* Update internal database according to current TZ setting.
579 POSIX.1 8.3.7.2 says that localtime_r is not required to set tzname.
580 This is a good idea since this allows at least a bit more parallelism.
581 By analogy we apply the same rule to gmtime_r. */
It seems that glibc's implementation of thread-safe is to skip calling tzset() internally to
set the timezone. As a result, my PHP4 appears to ignore putenv("TZ=<whatever>").
Possible solutions: 1) Use the new PHP4 php_<funct>_r functions defined in reentrancy.c, or 2)
call tzset() externally before calling localtime_r or gmtime_r. I tried both solutions with the
test script from bug #3977 and both solutions appear to work.
---------------------------------------------------------------------------
Full Bug description available at: http://bugs.php.net/?id=4732