PharData created from zip has incorrect timestamp

[danepowell]

Description

The attached zip file contains one text file with a modified time of 1680284661:
test.zip

Running this code in a directory with the zip file on macOS:

<?php
$phar = new PharData('test.zip');
print($phar->getMTime());

Resulted in this output:

1680317060

But I expected this output instead:

1680284661

Some people also get 1680284660 as output. Note that 1680317060 and 1680284661 are exactly 9 hours and 1 second apart, making me think this could be a timezone issue and the 1 second might be a rounding error.

Actually, I would perhaps expect the mtime to be that of the zipfile itself, not of its contents. I don't think the behavior of setting the mtime based on contents is documented anywhere. Regardless, the mtime should have some correlation to a real value 😄

PHP Version

8.2.11 from Homebrew

Operating System

macOS 13.6 (2021 Macbook Pro, Apple M1 Max)

[nielsdos]

I don't see the bug here?
The file inside the zip was modified at 31 March '23 19:44(GMT+2) or in UTC time: 17:44.
The time reported back by getMTime() is 31 March '23 19:44(GMT+2) or in UTC time: 17:44.
So they match.

Keep in mind that unix time is always the number of seconds since Jan 1 1970 in UTC.

[nielsdos]

Ah wait, your code actually returns 1680284660 on Linux so it is correct for me, but you're getting 1680317060...
Looks like a bug in getMTime then? I'll check more closely later.

[nielsdos]

The commit/issue you linked couldn't have introduced the issue, because prior to that commit the date was always in 1980.
I don't see how 1680317060 is possible, we also don't have apple-specific code. The bug does not manifest on Linux.
I don't have access to a macOS install, so someone else will have to debug this...

[devnexen]

I get same result in both Linux/macOs (same as posted, brew 8.2.11), GMT+1 1680288260

[nielsdos]

Thank you David.
@danepowell Please provide a full stand-alone reproducer. It's possible there's more going on as we can't reproduce it.