- Changed 'transform' method to use ValueInfo throughout. This fixes a number of obscure bugs
- Changed the 'add' and 'sub' methods to default to "now" rather than null. This means null passes through rather than being interpreted as the current time, to be consistent with other date tools
- Also changed the 'add' and 'sub' methods so that they operate correctly with invalid date strings
- Added tests for the class; improves #66
- Modified TTRSS tests because the "iso8601" format string in ValueInfo is different from Date's older format
Also move date formats to the ValueInfo class
Standardizing on immutables avoids any possible ambiguity in the API of the resultant value, as well as any ambiguity as to whether a DateTime output instance is the same instance or a clone (they had been clones)
This sees the addition of a dateOutFormat parameter to ValueInfo::normalize(), as well as a general simplification of how parameter binding works.
Some value type-casting results are slightly different, but this simply makes SQL statement objects consistent with the rest of the system.
The changes in this commit should make it more practical to:
- Allow the driver to decide for itself whether to try creating a PDO object if its own requirements are not met
- Have any driver use a generic schema update procedure
- Use the same constructor for native and PDO SQLite
Code coverage information is now gathered via phpdbg (a separate executable) by if available rather than xdebug, as the latter is hard to turn on and off.
A "test:quick" task has also been added to Robo, which excludes 31 tests which together account for almost two thirds of the test run time. This should pave the way for testing to be added as a commit hook for Git.
Though TTRSS itself (usually) omits items that have a counter of zero, at least one client takes this to mean the last-seen counter is unchanged, rather than zero.
Real-world use suggests 5s is inadequate. Rather than bumping up small amounts as things break, it makes more sense to wait a very long time and investigate possible long-term solutions later, once logging is implemented.
