ID:               25825
 User updated by:  pennington at rhodes dot edu
 Reported By:      pennington at rhodes dot edu
-Status:           Feedback
+Status:           Open
 Bug Type:         Date/time related
 Operating System: Windows 2000
 PHP Version:      4.3.3
 Assigned To:      wez
 New Comment:

Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we
are running does use putenv() in the following function:

----------------

/**
     * Is the given date/time in DST for this time zone
     *
     * Attempts to determine if a given Date object represents a
date/time
     * that is in DST for this time zone.  WARNINGS: this basically
attempts to
     * "trick" the system into telling us if we're in DST for a given
time zone.
     * This uses putenv() which may not work in safe mode, and relies
on unix time
     * which is only valid for dates from 1970 to ~2038.  This relies
on the
     * underlying OS calls, so it may not work on Windows or on a
system where
     * zoneinfo is not installed or configured properly.
     *
     * @access public
     * @param object Date $date the date/time to test
     * @return boolean true if this date is in DST for this time zone
     */
    function inDaylightTime($date)
    {
        $env_tz = "";
        if(getenv("TZ")) {
            $env_tz = getenv("TZ");
        }
        putenv("TZ=".$this->id);
        $ltime = localtime($date->getTime(), true);
        putenv("TZ=".$env_tz);
        return $ltime['tm_isdst'];
    }

-------------------

Are you saying that this could change the environment variable for
timezone for the entire server for good (at least until IIS5 is
restarted) once this code is executed? And this would affect pages that
don't even include the function above?


Previous Comments:
------------------------------------------------------------------------

[2003-10-14 12:15:49] [EMAIL PROTECTED]

The only other way to manipulate locale is via putenv(), which would
change LC_* environment variable.

------------------------------------------------------------------------

[2003-10-14 10:29:48] pennington at rhodes dot edu

I searched through all of the PHP code in use on this machine for the
setlocale() function and only found two entries, both of which were
commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other
code on that machine. In other words, we are only using it to serve PHP
pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5
if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that
manipulate the locale?

------------------------------------------------------------------------

[2003-10-13 18:41:27] [EMAIL PROTECTED]

Do any of your scripts use setlocale() or other similar function to
manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other
ISAPI you have there), and that it isn't being reset back to the system
default.

------------------------------------------------------------------------

[2003-10-13 17:53:32] pennington at rhodes dot edu

Interestingly, when testing to see if this UTC display of time would
happen for PHP installed as a CGI (couldn't reproduce with Apache2 or
IIS5 as a CGI), I noticed that the UTC time problem does not show up
right away with PHP installed as ISAPI on IIS5. Rather, when you stop
the IIS service and then start it again, for a period of time, the
correct time is displayed using echo date("D M j G:i:s T Y");

However, after a period of time passes (say an hour or so on a server
averaging a few users at a time), the time switches to UTC and does not
go back.

If you stop IIS and then start it again, the time goes back to the
correct time and the cycle starts again.

Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been
trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because
I've been having trouble getting the Windows 2000 Server, which uses
PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as
setting cgi.force_redirect = 0 and changing the app mapping
configuration to point to the php.exe and not the php4isapi.dll but I'm
not having any luck (get "not authorized to view this page" on php
scripts). This method works fine on the Win2K workstation. Anyway, this
is not related to the UTC time issue...

------------------------------------------------------------------------

[2003-10-13 12:14:05] [EMAIL PROTECTED]

Do you get the same problem running CGI?


------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/25825

-- 
Edit this bug report at http://bugs.php.net/?id=25825&edit=1

Reply via email to