They should fix the design then. And not wrongly implement stuff and make everybody follow their errors.

Of course you can fix it the Microsoft way, i.e. in the documentation: "On Windows platforms, file times obtained through stat() filemtime() etc will vary depending on your system's daylight saving time settings. According to Microsoft, 'This is by design.' For further reference see KB190315."

But since there is a known API that returns the right information, it would IMO be better to use it rather than do nothing and blame the [insert your expletives here] design. Fixing PHP stat() and co will improve cross-platform compatibility for PHP scripts. Doing nothing will not.

PHP already fixed a lot of MS-DOS things, like path separators, so it seems to me that implementing a fix for stat() would remain consistent with that policy.

We have a system that check file sizes and timestamps, to create a list. We need to keep this system on PHP 5.2.0, since this change was introduced in 5.2.1 due to windows optimalization (?) as far as I understand, and we cannot suddenly change the timestamps in the list.

Will this be handled/changed back in any way in PHP, or do we need to create some kind of workaround?

(Sorry for adding a bug report on this, when this [suspended] bug already exist)

Levi

The same "Microsoft feature" is found under Windows Server 2003, 64-bit.  Though previous test cases are well done, this one may be helpful as well:

Try this experiment:

$timestamp_str = "2005.02.06 14:45:33";
$timestamp_pieces=split('[. :]',$timestamp_str);
$timestamp=mktime($timestamp_pieces[3], $timestamp_pieces[4], $timestamp_pieces[5], $timestamp_pieces[1], $timestamp_pieces[2], $timestamp_pieces[0]);
touch("c:\\timestamp_test.txt",$timestamp);

The file timestamp_test.txt shows up in the operating system as having a modification date of "Sunday, February 06, 2005, 2:45:33 PM" - which is the desired result.

But now look at the results of filemtime (only when in DST - it will report the correct timestamp during standard time):

$compare_timestamp=filemtime("c:\\timestamp_test.txt");
$compare_timestamp_str = date("Y.m.d H:i:s",$compare_timestamp);
echo "$timestamp ($timestamp_str) is the original timestamp.<br />\n";
echo "$compare_timestamp ($compare_timestamp_str) is the timestamp on the file.<br />\n";

The output looks like this:

1107726333 (2005.02.06 14:45:33) is the original timestamp.
1107722733 (2005.02.06 13:45:33) is the timestamp on the file.

The filemtime function reports a timestamp different from what the OS reports.

I understand the "Microsoft should do it right" concept.  But this issue is forcing me to have different PHP code based on the server OS - something I've not had to do much until now.

I've build a PHP extension to workaround this ...

http://www.steelbytes.com/?mid=46

Very easy reproduce code (should try it during daylight saving time):

<?php
  $fullfilename='test.dll';
  $ft=filemtime($fullfilename);
  touch($fullfilename.'.md5',$ft);
  $nt=filemtime($fullfilename.'.md5');
  echo $ft.' : '.$nt;
?>

Please get test.dll from http://www.vezz.it/php/test.zip

Original file modification date: 19 feb 2008, 19.08.47

The script output:
1203440927 : 1203437327

The touched file date is one hour back.
19 feb 2008, 18.08.47 instead of 19 feb 2008, 19.08.47

In my opinion, this should really be fixed.

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I changed the underlying code to use the windows native APIs. Please try it.

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".

We use the new API now in 5.3+.

The fix in 5.3 fixes the problem with the file times reported for NTFS volumes but introduces the problem with file times returned for files in FAT volumes. Now the file times for FAT volumes are not constant across day light saving changes. To keep these constant for FAT volumes Windows stat function should be used.