Using tzselect on Debian leads to the assumption that your TZ variable should probably be "America/Los_Angeles" (with underscore). Can you test that, please?

Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.

I did this, using export TZ='America/Los_Angeles' and restarted apache.  It made no difference to the php script output. 

In other words, if php believes that the server timezone is 'America/Los_Angeles' it gives the incorrect time.  But if it believes that timezone is 'US/Pacific' it gives the correct time.  However, setting TZ to 'US/Pacific' also makes no difference to the script output.  So I'm wondering where PHP is picking up the timezone information from and how I can get it to believe that the timezone is 'US/Pacific' from startup.  Can I set that in php.ini?

(Also, there are two timezone commands on debian, tzselect and tzconfig.  tzconfig lets one choose either 'US/Pacific' or 'America/Los_Angeles' for the timezone, but neither makes a difference to this script).

"apachectl restart" does not pick up the new TZ environment variable. Did you try apachectl stop / apachectl start? I get the same results as you with TZ="America/Los Angeles", but "America/Los_Angeles" or "US/Pacific" work. As far as I know there's no php.ini setting that fiddles with timezones.

here's what I do, as root:

# export TZ='America/Los_Angeles'
# set | grep TZ
# TZ=America/Los_Angeles
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# apachectl start
/usr/sbin/apachectl start: httpd started


output of the php script: 

server timezone is: America/Los Angeles
server time is: February 9, 2003, 7:51 pm
changing server time zone to US/Pacific....
new server time is: February 9, 2003, 11:51 am
new server timezone for this script is: US/Pacific

I notice that PHP does not pick up the underscore in "Los_Angeles".

What I wondered was whether there's a way to do the equivalent of putenv("TZ=US/Pacific") in php.ini?

However, I have just noticed that the time is wrong in OTRS running on the same server -- and it is a set of perl scripts.  So maybe this is not a PHP bug at all?

You don't have a

  SetEnv TZ "America/Los Angeles"

in your httpd.conf, do you? Or maybe TZ is fixed in your apachectl script?

no, TZ is not being set in httpd.conf nor in apachectl.

Experiment #1
What happens if we use putenv("TZ=US/Los_Angeles")?

the script:

<?
print("server timezone is: " . getenv('TZ') . "<br>\n");
print("server time is: " . date("F j, Y, g:i a") . "<br>\n");
print("changing server time zone to US/Los_Angeles....<br>\n");
putenv("TZ=US/Los_Angeles");
 print("new server time is: " . date("F j, Y, g:i a") . "<br>\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

here's the output, with the incorrect times:

server timezone is: America/Los Angeles
server time is: February 22, 2003, 5:01 pm
changing server time zone to US/Los_Angeles....
new server time is: February 22, 2003, 5:01 pm
new server timezone for this script is: US/Los_Angeles
output of date(T):US/Los_Angeles


Experiment # 2:

I also tried putting 

SetEnv US/Pacific

into httpd.conf.

this script:

 print("server timezone is: " . getenv('TZ') . "<br>\n");
 print("server time is: " . date("F j, Y, g:i a") . "<br>\n");
print("changing server time zone to US/Pacific....<br>\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "<br>\n");
print("new server timezone for this script is: " . getenv('TZ'));

produces this output:

server timezone is: US/Pacific
server time is: February 22, 2003, 5:29 pm
changing server time zone to US/Pacific....
new server time is: February 22, 2003, 9:29 am
new server timezone for this script is: US/Pacific
output of date(T):PST

In this case, PHP picks up the US/Pacific timezone from the environment, but gets the time wrong!

Experiment # 3

try with SetEnv = US/Los_Angeles in httpd.conf

same script as #2, produces bad output:

server timezone is: US/Los_Angeles
server time is: February 22, 2003, 5:34 pm
changing server time zone to US/Pacific....
new server time is: February 22, 2003, 9:34 am
new server timezone for this script is: US/Los_Angeles
output of date(T):PST

So it seems to be the case that the ONLY way to get PHP to have the correct time is to use putenv("TZ=US/Pacific") in a script.

Any other ideas?  Thanks for your help

I don't see a /usr/share/zoneinfo/US/Los_Angeles on Debian, only
America/Los_Angeles (and US/Pacific). So I suggest you try again with America/Los_Angeles.

You're right. I should have used "America/Los_Angeles".

results: experiment #1, using
 putenv("TZ=America/Los_Angeles");

php produces the correct time after this, but not before (that is, doesn't pick up TZ from the system).

experiment # 3, SetEnv TZ=America/Los_Angeles in httpd.conf
has no effect -- the time is still wrong until I use putenv with either "US/Pacific" or "America/Los_Angeles".

SetEnv in httpd.conf has no effect on PHP.
You should set the timezone correctly before you _start_
apache, in the shell..

As your first script mentioned, the output for
getenv('TZ') was "America/Los Angeles" which is wrong..

sniper@php.net wrote:
<snip>
You should set the timezone correctly before you _start_
apache, in the shell..</snip>

I tried that..see my posting below from 9 Feb 1:54pm. Even when TZ is set correctly in the shell to 'America/Los_Angeles' before starting apache, php's getenv('TZ') reports "America/Los Angeles" as the timezone. If I set TZ to 'US/Pacific' in the shell, stop and start apache, php still reports the timezone incorrectly as "America/Los Angeles".  So, if PHP does not seem to be picking up the timezone from the environment.  Again, the only way I can affect the timezone is using putenv(). 

Not sure where to go from here.  Perhaps pull from CVS and recompile?

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I rebuilt php a while after my Feb 25th posting, and the problem mysteriously went away. Since I run the testing dist of Debian and update with apt regularly (almost daily), there's a good chance that some other package got changed and that's what fixed the problem.