Allow BC for nullish DB values as strings.

[dereuromark]

When working with legacy apps/DBs, there often is the (valid in MySQL) string value 0000-00-00 ... used for NULL. That currently breaks terribly, as it is converted to a negative value in Carbon:

object(Cake\I18n\Time) {
    'time' => '-0001-11-30T00:00:00+0000',
    'timezone' => 'UTC',
    'fixedNowTime' => false
}

making "empty" comparisons difficult.

And then on top throws errors like

IntlDateFormatter::format(): datefmt_format: error calling ::getTimeStamp() on the object [CORE\src\I18n\Time.php, line 597]

This is an easy fix here for BC and doesn't hurt IMO.

PS: "MySQL permits you to store a “zero” value of '0000-00-00' as a “dummy date.” This is in some cases more convenient than using NULL values, and uses less data and index space" https://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html Even though people really should be using NULL here as default value :)

[lorenzo]

I'm ok with this

[markstory]

Why not check for allballs specifically? Int casting will fail on '0000-01-01 00:00:00' which is a 'valid' date.

[dereuromark]

Well, that date is not null (as in null worthy) per se, so I wouldn't want to catch/support that either way.

You are right, specific check would be better in that case. But only on the first part of this string to also support date (0000-00-00) then, as well.
So this was a compromise to handle it quickly.

So better

substr($string, 0, 10) === '0000-00-00'

then

[dereuromark]

According to some sources The concept of a year "zero" is a modern myth (but a very popular one). In our calendar, C.E. 1 follows immediately after 1 B.C.E.
So we dont have to support 0000-...

[markstory]

ok.