The PHP function filemtime returning a negative value or very large value

Question

I am creating a WordPress plugin and can see that on some servers, for certain files, the stat (or filemtime) returning invalid mtime value. In some cases it is a negative value or a very large value (more than 3 billion).

In FTP I can see that the timestamp is correct though.

+3bill isn't too likely, unless you're on a 64bit system. +3 bill is impossible for a standard signed 32bit timestamp, and would correspond to ~2065 anyways if you are in 64bit territory. — Marc B, Dec 13 '12 at 20:46
Possible duplicate http://stackoverflow.com/questions/11718772/php-filemtime-function-showing-wrong-date — Mike, Dec 13 '12 at 20:57
The filepath is surely correct. When I overwrite the file, the timestamp is getting reported correctly. I am guessing the 3billion+ is correlated to the negative value where the highest order bit is being interpreted incorrectly. What I don't follow is, how can the highest order bit get set? — akshat, Dec 14 '12 at 07:23
This should trigger some warnings though; have you set error_reporting to the highest level? — Ja͢ck, Dec 16 '12 at 12:15
The question that should be asked is, are you on a windows system or a unix system? — Mike Mackintosh, Dec 19 '12 at 16:23
What file system are you using? NTFS, ext3/4, ReiserFS, tempfs??? This matters. PHP's file system functions are known to have strange behavior on certain systems. This is because some file systems store/interpret `mtime` very differently. — Sherif, Dec 22 '12 at 19:52

score 11 · Answer 1 · answered Dec 17 '12 at 10:13

11

When you get Negative numbers in any PHP timestamp its just the amount of seconds before the Unix Epoch and this is not limited to filemtime

Example A

echo strtotime("1950-1-1"); // Outputs  -631155600
                                        ^------- negative value

Example B

Outputting negative values does not mean you can not format it correctly if you try

echo date("Y-m-d",-631155600); // Output  1950-01-01

Lastly

FTP I can see that the timestamp is correct though

Your FTP application is definitely not PHP and has its own internal date system .. its Date System might not use negative values in timestamp

answered Dec 17 '12 at 10:13

Baba

94,024
28
166
217

thats a very old server if it has files modified before 1970 :) – Hugo Delsing Dec 20 '12 at 05:42
1

It can be wrong system configurations when the files where created – Baba Dec 20 '12 at 07:00
Would you know why the timestamp is becoming very large? – akshat Dec 22 '12 at 13:31
@akshat how large ... give a sample value – Baba Dec 22 '12 at 22:55
@baba 3421738619 this is one of the values we got – akshat Dec 24 '12 at 11:01

score 0 · Answer 2 · answered Dec 13 '12 at 20:44

0

If I understand you correctly, a very large value is what you're looking for- this is a Unix Time Stamp.

Did you try something like this?

date ("F d Y H:i:s.", filemtime($filename))

filemtime returns the number of seconds that have passed since January 1, 1970, which should be a very large value indeed; it's up to you to convert those seconds into something human-readable, using something like the above example.

If, on the other hand, you're aware of this and you believe your large value is still wrong, it may be helpful to post an example of said value, along with the date you're expecting for it.

answered Dec 13 '12 at 20:44

username tbd

9,152
1
20
35

Large, yes. Over three billion, no. – Niet the Dark Absol Dec 13 '12 at 20:47
@Kolink, certainly not over three billion, but likely over one billion, if I'm not mistaken. Figured the "3 billion" may have been a miscalculation, as `filemtime` returning anything else seems unlikely. – username tbd Dec 13 '12 at 20:49
I understand the timestamp is the "number of seconds since 1970". However, it should not get so large a value. For example, I am getting the value: 3421738619 – akshat Dec 14 '12 at 07:26

score 0 · Answer 3 · answered Dec 16 '12 at 15:10

0

When your server run a ntp daemon this could be a result of setting the time within a request. This happens e.x. for apache logs and other things that rely on unix system functions, too.

answered Dec 16 '12 at 15:10

Mario Mueller

1,450
2
13
16

score 0 · Answer 4 · answered Dec 19 '12 at 11:38

What size are the files that return a negative value for filemtime?

It says here: http://php.net/manual/en/function.stat.php that "Because PHP's integer type is signed and many platforms use 32bit integers, some filesystem functions may return unexpected results for files which are larger than 2GB."

score 0 · Answer 5 · answered Dec 22 '12 at 17:38

0

The current value of the unix timestamp is about 1,356,197,722 so a billion is reasonable.

Though it's unlikely to be the issue, it is worth knowing about http://php.net/manual/en/function.clearstatcache.php and using it before calling filemtime().

answered Dec 22 '12 at 17:38

Ray Paseur

2,106
2
13
18

The PHP function filemtime returning a negative value or very large value

5 Answers5