Y2038 Problems?

[oleibman]

This is:

- [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:

• Document/Properties
• Reader/Gnumeric
• Reader/Ods
• Reader/Xml
• Reader/Ods/Properties
• Reader/Xlsx/Properties
• Worksheet/AutoFilter

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:

• jpgraph
• 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.

[oleibman]

PR #1891 addresses two specific problems.

[oleibman]

PR #2113 makes "date created", "date modified", and custom date properties 32-bit safe. The following uses of strtime remain in src:

• Reader/Ods
• Reader/Gnumeric/Properties (2)
• Reader/Xml/Properties
• Worksheet/AutoFilter (10) (also the only remaining user of mktime/gmmktime)

[oleibman]

Use of strtotime in Reader/Ods is 32-bit safe, so only the other 3 need to be addressed.

[oleibman]

Gnumeric and XML PR's are ready. Autofilter will take a lot more time.

[oleibman]

Gnumeric and XML now taken care of. Working on AutoFilter.
BTW, it looks like PHP8.1 will finally address post-epoch DST.

[oleibman]

PR #2141, which deals with many of the AutoFilter problems, has been merged.
PR #2162 , which, I hope, deals with the rest of the AutofFilter problems, has been pushed.

[oleibman]

Filed bug report https://bugs.php.net/bug.php?id=81287 for PHP8.1 implementation of DateTimeZone::getTransitions. Its use is already replaced with an equivalent working function in PhpSpreadsheet.

[oleibman]

Potential problems are fixed. I could certainly be overlooking something, but I think this can be closed now.