PHP 4.0 Bug #4732: timezone woes

From: Date: Wed, 31 May 2000 15:43:29 +0000
Subject: PHP 4.0 Bug #4732: timezone woes
Groups: php.dev 
Request: Send a blank email to php-dev+get-19899@lists.php.net to get a copy of this message
From: ej@code-energy.com Operating system: Linux Mandrake 7.0 PHP version: 4.0.0 Release PHP Bug Type: Misbehaving function Bug description: timezone woes 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.

« previous php.dev (#19899) next »