mirror of
https://github.com/PHPOffice/PhpSpreadsheet.git
synced 2026-08-23 18:52:17 +00:00
oleibman
04e7c30758
I ran the test suite using 32-bit PHP. There were 2 places where changes were needed due to 32-bit timestamps. Reader\\Xml.php was using strtotime as an intermediate step in converting a string timestamp to an Excel timestamp. The XML file type stores pure timestamps (i.e. no date portion) as, e.g., 1899-12-31T02:30:00.000, and that value causes an error using strtotime on a 32-bit system. However, it is sufficient to use that value in a DateTime constructor, and that will work for 32- and 64-bit. There was no test for that particular cell, so I added one to the XML read test. And that's when I discovered the getFormattedValue bug. The cell's format is `hh":"mm":"ss`. The quotes around the colons are disrupting the formatting. PhpSpreadsheet formats the cell by converting the Excel format to a Php Date format, in this case `H\:m\:s`. That's a problem, since Excel thinks 'm' means *minutes*, but PHP thinks it means *months*. This is not a problem when the colon is not quoted; there are ample tests for that. I added my best guess as to how to recognize this situation, changing `\:m` to `:i`. The XML read test now succeeds, and no other tests were broken by this change. Test Shared\\DateTest had one test where the expected result of converting to a Unix timestamp exceeds 2**32. Since a Unix timestamp is strictly an int, that test fails on a 32-bit system. In the discussion regarding recently merged PR #1870, it was felt that the user base might still be using the functions that convert to and from a timestamp. So, we should not drop this test, but, since it cannot succeed on a 32-bit system, I changed it to be skipped whenever the expected result exceeded PHP_INT_MAX. There are 3 "toTimestamp" functions within that test. Only one of these had been affected, but I thought it was a good idea to add additional tests to the others to demonstrate this condition. In the course of testing, I also discovered some 32-bit problems with bitwise and base-conversion functions. I am preparing separate PRs to deal with those.
51 lines
840 B
PHP
51 lines
840 B
PHP
<?php
|
|
|
|
// Excel DateTimeStamp Result Comments
|
|
|
|
return [
|
|
[
|
|
-1956528000,
|
|
1462,
|
|
],
|
|
[
|
|
-1956441600,
|
|
1463,
|
|
],
|
|
[
|
|
-158803200,
|
|
22269,
|
|
],
|
|
[
|
|
126316800,
|
|
25569,
|
|
],
|
|
[
|
|
534384000,
|
|
30292,
|
|
],
|
|
[
|
|
1339545600,
|
|
39611,
|
|
],
|
|
// 06:00:00
|
|
[
|
|
gmmktime(6, 0, 0, 1, 1, 1904), // 32-bit safe - no Y2038 problem
|
|
0.25,
|
|
],
|
|
// 08:00.00
|
|
[
|
|
gmmktime(8, 0, 0, 1, 1, 1904), // 32-bit safe - no Y2038 problem
|
|
0.3333333333333333333,
|
|
],
|
|
// 13:02:13
|
|
[
|
|
gmmktime(13, 02, 13, 1, 1, 1904), // 32-bit safe - no Y2038 problem
|
|
0.54321,
|
|
],
|
|
// 29-Apr-2038 00:00:00 beyond PHP 32-bit Latest Date
|
|
[
|
|
2156112000,
|
|
49062,
|
|
],
|
|
];
|