Document Properties - Coverage and 32-bit-safe Timestamps

[oleibman]

While researching an issue, I noticed that coverage of Document/Properties was poor. Further, the use of int timestamps will eventually lead to problems for 32-bit PHP (see issue #1826).

Coverage Changes:

• Many property types with no special handling are enumerated but not tested. These are removed, but will continue to function as before.
• Existing code theoretically allows property to be set to an object, but there is no means to read or write such a property, and, even if there were, I don't believe Excel supports it. Setting a property to an object will now be changed to a no-op (can throw an exception if preferred).
• Since the Properties object now has no members which are themselves objects, there is no need for a deep clone. The untested __clone method is removed.
• Large switch statements are replaced with associative arrays. Scrutinizer will like that.
• Coverage is now 100%.

Timestamp Changes:

• Timestamps will be stored as int if possible, or float if not. This is, or will soon be, needed for 32-bit systems. Tests have been added for beyond-epoch dates, and run successfully with 32-bit.
• LibreOffice doesn't quite get the Created/Modified properties correct. These are written to the file as a string which includes offset from UTC, but LibreOffice ignores the offset portion when displaying them. Code had been generating these in UTC, but now generates them in default timezone, which should meet user's expectations.

Other Changes:

• Custom properties added to ODS Writer.
• Samples had not been generating any ODS files. One is now generated.
• Ods uses a single 'keywords' property rather than multiple 'keyword' properties.
• Breaking change - default company is changed to null string from Microsoft Corporation.
• Breaking change of sorts - PropertiesTest incorrectly tested a custom date property against a string, Reader/XlsxTest correctly tested against a timestamp converted to a string. PropertiesTest was defective, and will no longer work as coded; anyone using it as a model will likewise have a problem.
• PHP8.1 has been complaining for weeks about a time zone conversion test. I have now downloaded a version, and changed the code so that it will work in 8.1 as well as prior releases. (It is still likely that the existing code should work in 8.1, but I haven't yet figured out how to file a bug report.) In the course of testing, 3 additional 8.1 problems were reported (all along the lines of "can't pass null to strpos"), and are fixed with null coercion.
• Two Calculation tests failed because of large results on 32-bit system. These are corrected by allowing the functions involved to return float|int rather than int. I suspect that there are other functions with this problem, and will investigate as a follow-up activity.
• See issue Argument 1 passed to PhpOffice\PhpSpreadsheet\Writer\Xls::writeSummaryProp() must be of the type string, null given #2090. I believe that changes between 17.1 and master will merely cause the problematic spreadsheet to fail in a different way. I believe that enclosing in quotes some variables passed to Document/Properties by Reader/Xlsx will eliminate the problem, but, in the absence of an example file, cannot say for sure.
• Properties tests are now separated out from Reader/XlsxTest and Reader/OdsTest, and now test both Read and Write (via reload).

Miscellaneous Notes:

• There remains no support for Custom Properties in Xls Reader or Writer.
• We now have default timezones for all of PHP itself, Shared/Date, and Shared/Timezone. That is least one too many. I was unable to disentangle the latter two for this change, but will look into deprecating one or the other in future.

This is:

- [x] a bugfix
- [ ] a new feature

Checklist:

• Changes are covered by unit tests
• Code style is respected
• Commit message explains why the change is made (see https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
• CHANGELOG.md contains a short summary of the change
• Documentation is updated as necessary

Why this change is needed?

[MarkBaker]

With so many smaller changes as well, this took a while to review

Is it possible to do smaller, dedicated ("atomic") commits in future; then I can work through one commit at a time

[oleibman]

Noted. I could certainly have isolated the 32-bit non-timestamp changes, and the PHP8.1 Calculation changes, and maybe the issue 2090 change, into their own PRs, and will try to do so in future. I don't always test in those environments, and, when I do, it's hard to let go of the idea that I need to fix minor failures that show up (so that my local tests will fully succeed) even though such failures won't cause a problem for the PR. But I had not been considering that from a reviewer's perspective.

[MarkBaker]

Large PRs aren't normally too much of a problem to review, as long as they are a series of small, atomic commits, when a reviewer can assess each of the individual commits (and even "cherry pick" if appropriate).... and I'm just as guilty as anybody about that