Set date.timezone to your timezone.

Setting date.timezone does not change the behaviour.  Changing the sample script to:

<?php

echo "default timezone: " . date_default_timezone_get() . "\n";

date_default_timezone_set("Australia/Brisbane");

echo "default timezone: " . date_default_timezone_get() . "\n";

echo date('Y-m-d H:i:s', filemtime($_SERVER["SCRIPT_FILENAME"])) . "\n";


produces this output:

$ php test_filemtime.php
default timezone: Australia/Melbourne
default timezone: Australia/Brisbane
2006-07-22 20:35:22

Which is still 9 hours greater than it should be.

When using Apache2 SAPI, the following (correct) output is generated:

default timezone: Australia/Melbourne
default timezone: Australia/Brisbane
2006-07-22 11:35:22


Changing "Australia/Brisbane" to "UTC" changes the time that is printed, however there is still a 9 hour difference between the value printed by CLI (2006-07-22 10:39:47) and the value printed by Apache2 SAPI (2006-07-22 01:39:47)

Can you get rid of the date() calls so that we can rule out that that is the problem and not filemtime?

Changed test_filemtime.php to:

<?php

echo filemtime($_SERVER["SCRIPT_FILENAME"]) . "\n";
date_default_timezone_set("UTC");
echo filemtime($_SERVER["SCRIPT_FILENAME"]) . "\n";


Output is:

$ php test_filemtime.php
1153659348
1153659348


So, the return from filemtime() is not affected by the date.timezone setting.  However the value is out by 9 hours.  This is the expected return value: 

$ stat -c%Z test_filemtime.php
1153626948

(this matches very closely the output of date +%s, as I had just saved the file when running the above command)

And the difference is 9 hours

$ echo $((1153659348-1153626948))
32400

$ echo $((9*3600))
32400

Unassigning as this has nothing to do with the date code.

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

Not reproducible.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I'm having the same issue of filemtime() reporting 9 hours ahead of when it is suppose to
I'm on Windows XP running PHP v5.2.0
I tested this on Linux running PHP v5.1.6 and it reported correctly.
In my opinion it's a bug relating to PHP under Windows XP.

Nevermind about my last comment. This bug has been fixed in latest version of PHP. I should have tried this first.