php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #4732 timezone woes
Submitted: 2000-05-31 17:43 UTC Modified: 2001-01-09 04:06 UTC
From: ej at code-energy dot com Assigned:
Status: Closed Package: *General Issues
PHP Version: 4.0.0 Release OS: Linux Mandrake 7.0
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ej at code-energy dot com
New email:
PHP Version: OS:

 

 [2000-05-31 17:43 UTC] ej at code-energy dot 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-07-02 05:10 UTC] sterling at cvs dot php dot net
This is fixed in PHP4.0.1
 [2001-01-09 04:06 UTC] sniper@php.net
Fixed in CVS.

--Jani
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed Feb 05 17:01:30 2025 UTC