In one file, the timestamp returned for "Zip Modify Date" is 2020:05:06 01:22:60
This appears to be a bug. If it's not a bug, should the seconds component of the timestamp be considered the same as 00?
Here is the output from 12.00, and I have checked using the latest 12.01. Both have the same output. Also, I have tested this on macOS and Windows. Same results.
$ exiftool P.O.xlsx
ExifTool Version Number : 12.00
File Name : P.O.xlsx
Directory : .
File Size : 11 kB
File Modification Date/Time : 2020:05:07 07:19:00-04:00
File Access Date/Time : 2020:07:22 10:32:30-04:00
File Inode Change Date/Time : 2020:07:20 15:28:02-04:00
File Permissions : rwxr-xr-x
File Type : XLSX
File Type Extension : xlsx
MIME Type : application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Zip Required Version : 20
Zip Bit Flag : 0x0002
Zip Compression : Deflated
Zip Modify Date : 2020:05:06 01:22:60
Zip CRC : 0xd07cf71a
Zip Compressed Size : 388
Zip Uncompressed Size : 1505
Zip File Name : [Content_Types].xml
Creator :
Last Modified By :
Create Date : 2006:09:16 00:00:00Z
Modify Date : 2020:05:05 14:24:23Z
Application : Microsoft Excel
Doc Security : None
Scale Crop : No
Heading Pairs : Worksheets, 1
Titles Of Parts : Sheet2
Links Up To Date : No
Shared Doc : No
Hyperlinks Changed : No
App Version : 12.0000
$ exiftool -ver
12.00
That's odd. The ZIP file date/time conversion is not subject to round-off errors, so this must have been the way it was stored. I don't think there is anything that should be changed in ExifTool for this. The seconds are stored separately in 5 bits of the date/time value, with a resolution of 2 seconds. Maybe the writing software rounded up from 59 to 60 since odd seconds can't be represented?
- Phil