- [x] a bug report - [ ] a feature request - [ ] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)
What is the expected behavior?
Software should continue to work after epoch change in 2038.
What is the current behavior?
Running on 64-bit Php is probably okay. 32-bit may have problems.
What are the steps to reproduce?
Too early? I think not. YMMV. The analysis below is probably not complete, but it's a start.
PHP itself has some Y2038 exposure (e.g. see https://bugs.php.net/bug.php?id=64992). Dealing with these is clearly out of scope for PhpSpreadsheet.
I think that PhpSpreadsheet is pretty well positioned to avoid problems. However, it does use functions mktime, gmmktime, and strtotime. Those functions will work just fine after the Y2038 transition when 64-bit PHP is used. However, they will fail when 32-bit PHP is used. It is hard to guess if 32-bit PHP will even be a thing when the time comes, but it's best to be prepared. I don't know that it is possible to make 64-bit a requirement, and, even if it is, doing that seems far too drastic. On the other hand, it should be possible to have the unit tests run in a 32-bit region. I don't know how to arrange that. I would suggest that it is probably sufficient to run one 32-bit region rather than a 32-bit version of each supported release of PHP.
Scanning the source code, I find the following use of mktime/gmmktime:
- samples/templates/SampleSpreadsheet - gmmktime is used to populate one cell with the current date. This is very easily solved by instead using DateTime (which is supported beyond the epoch even on 32-bit systems), and I have a PR which I will be pushing shortly to address this.
- Worksheet/Autofilter and 3 samples/10_Autofilter*. This is likely to fail before the others, since the tests involve filtering on future dates.
- Shared/OLE - this looks fairly easy to recode, although research is needed to come up with suitable test cases.
The use of strtotime is more extensive. I haven't researched any of these:
Scanning the vendor directory, the only uses of mktime/gmmktime that I see are in jpgraph, which is already problematic because it isn't supported through Composer. Again, I think this is out of scope. There is more extensive use of strtotime:
- 1 use in phenx
- 2 uses in symfony/finder, plus tests for symfony/finder
- 1 use in tcpdf_static
My reading of the documentation for the strftime, localtime, date, and time functions, which take a timestamp argument, suggests that they may also be problematic after the epoch, especially when the timestamp argument is omitted. If so, this is probably a problem that PHP needs to address. For the record, Calculation/DateTime uses some of these.
Which versions of PhpSpreadsheet and PHP are affected?
AFAIK, only 32-bit PHP is affected.