DateObject accepts "0" as a valid month, day or year.

If I enter a date '0000-00-00' into a date textfield, it is recorded as today's date (even if 'No default value' is given, see
#1995864: Date field not obey 'No default value' (defaults to current date) when within Field Collection or Paragraph.

If I apply only the last hunk of the patch in #5, this problem seems to be fixed and it still passes the date API tests.

Forget my last comment, the tests pass but my problem was not fixed.

I should add that I'm using a d-m-Y day format (so in my case it's "00-00-0000", not "0000-00-00").
I didn't think that would matter, but it does:

drush ev 'var_dump(new DateObject("0000-00-00"));'
object(DateObject)#9 (10) {
  ["granularity"]=>
  array(4) {
    [0]=>
    string(4) "year"
    [1]=>
    string(5) "month"
    [2]=>
    string(3) "day"
    [3]=>
    string(8) "timezone"
  }
  ["errors"]=>
  array(0) {
  }
  ["serializedTime":"DateObject":private]=>
  NULL
  ["serializedTimezone":"DateObject":private]=>
  NULL
  ["timeOnly"]=>
  bool(false)
  ["dateOnly"]=>
  bool(false)
  ["originalTime"]=>
  string(10) "0000-00-00"
  ["date"]=>
  string(20) "-0001-11-30 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Berlin"
}

This is wrong, it should be "0000-00-00 00:00:00".

drush ev 'var_dump(new DateObject("0000-00-00", "Europe/Berlin", "Y-m-d"));'
object(DateObject)#9 (10) {
  ["granularity"]=>
  array(7) {
    [0]=>
    string(4) "hour"
    [1]=>
    string(6) "minute"
    [2]=>
    string(6) "second"
    [3]=>
    string(5) "month"
    [4]=>
    string(3) "day"
    [5]=>
    string(4) "year"
    [6]=>
    string(8) "timezone"
  }
  ["errors"]=>
  array(0) {
  }
  ["serializedTime":"DateObject":private]=>
  NULL
  ["serializedTimezone":"DateObject":private]=>
  NULL
  ["timeOnly"]=>
  bool(true)
  ["dateOnly"]=>
  bool(false)
  ["originalTime"]=>
  string(10) "0000-00-00"
  ["date"]=>
  string(19) "2014-01-23 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Berlin"
}

This is also wrong.

OK, maybe the -0001-11-30 value makes some sense since month 0 would be the month prior to month 1, etcetera. The date_api module says

    // If the input value is '0000-00-00', PHP's date class will later
    // incorrectly convert it to something like '-0001-11-30' if we do setDate()
    // here. If we don't do setDate() here, it will default to the current date
    // and we will lose any way to tell that there was no date in the orignal
    // input values. So set a flag we can use later to tell that this date
    // object was created using only time values, and that the date values are
    // artifical.

But on https://bugs.php.net/bug.php?id=42971 it says that this is not a bug.

Anyway, I think

new DateObject("0000-00-00")

and

new DateObject("0000-00-00", "Europe/Berlin", "Y-m-d")

should return the same value. The patch should fix it I believe.

Lets focus on this issue and get it in ASAP

Let's add some test...

Ok, lets get this in. Keeping it RTBC and assigning to @podarok for final review and commit.

Re-rolled!

This Patch will solve the issue

As has been explored in many other issues, date-only and time-only values are not a reality when saving things in the database. There does exist dateOnly and timeOnly flags in the code, but they don't do much.

This patch needed a little more than a re-roll to work properly but I think I've got it as far as preventing zero month and zero day entries. Any changes or suggestions or questions would be welcomed. This is basically one of the most used modules in D7 so I understand the implications of what's been changed here.

Thank you scottm316 for the patch.

Would someone mind testing the patch in #26 to see if it resolves your problems? Thanks.

The test files have been renamed, so this needs a reroll.

I tried to re-roll the patch acommodating the changes in the module, but the problem remains.

If you could please upload the patch it'd be a step forwards. Thank you.

Submitting patch. I hope it may help!

Thank you, I appreciate it!

I think there might be a typo here:

+          if (empty($value)) {
+            $this->erros['month'] = t('The month is invalid.');
+          }

Sorry! indeed I notice this mistake and corrected it, but forgot to update the patch!

I fixed the typo.

Tests only.

Tests-only patch fails, full patch passes, this is great!

I see no problems with the patch, makes the test pass. RTBC from me.

Checking patch date_api/date_api.module...
Checking patch date_api/tests/DateApiTestCase.test...
Hunk #1 succeeded at 361 (offset 15 lines).
Hunk #2 succeeded at 374 (offset 15 lines).
Hunk #3 succeeded at 419 (offset 15 lines).
Applied patch date_api/date_api.module cleanly.
Applied patch date_api/tests/DateApiTestCase.test cleanly.

Committed. Thank you all!