Malformatted dates are accepted as valid and stored incorrectly.

Additional note (since I can't edit the original issue to clarify): In case this isn't clear, for the first few observations, the output was short U.S. format since we hadn't configured our default time formats in date/time settings. Even so, there are issues with what is stored, regardless of output format used for display (and there are additional issues with regard proper default output, once settings are made).

Title of issue changed to be a bit more clear. It's really an issue of date input formats not being fully validated.

Thanks for looking into this, KarenS

I'll work on creating a SimpleTest environment to streamline the process for you and make sure things are clear. It won't provide exhaustive tests, but should "fail" to reject input that isn't valid for the date format selected, at least to reproduce the most basic parts of the environment I was testing. Since our use case only includes EU-formatted dates, I didn't test whether bad values might also be accepted for U.S.-format, but I can start by checking that.

Short version of the issue I observed:
- Use EU date format (day/month/year)
- Enter a date with a too-high "month" and watch it get accepted as valid (and stored in strange ways).

Currently there appears to be no validation to reject a "month" higher than 12, so the months "roll over" and the date is stored as the next year. That's a PHP feature which can be useful, but I don't think we want users to be able to input dates that aren't validly formatted and have them re-interpreted in this manner.

Thanks, weboholic... I don't think the JS popup is needed. Or at least this happens when JS is disabled, too.

The JS widget is nice since it ensures dates get entered properly, but if JS is disabled or the user can't make use of the widget for some reason, entry mistakes could happen, so it would be good to improve validation of date strings entered.

Update: I poked around and found that it doesn't matter what the specified date format is, the module isn't performing checks to ensure the month and day values are within expected ranges.

I added a "malFormedDate()" method (a small variation on the existing "formDate" method) to the date.test file and inserted a call to it at the end of the testFieldUI() function.

In my example date, both the day and the month are "out of range" and get "rolled over" to the next month and year. The date format is mm/dd/yyyy and what is entered is 15/49/2011, which gets interpreted, quite sensibly, as 04/18/2012 (the 15th month of 2011 would be the third month of 2012. And the 49th day of that month, would be the 18th of the next month. It all makes perfect sense, but I don't think we want to accept such dates from users. ;-)

You can see the relevant part of the "verbose text" test results in the attached screenshot and the attached patch adds the following to the test:

>
  function malFormedDate($options, $date_format = 'mm/dd/yyyy') {
    // Tests that date field filters improper dates.
    $edit = array();
    $edit['title'] = $this->randomName(8);
    $edit['body[und][0][value]'] = $this->randomName(16);
    if ($options == 'select') {
      $edit['field_test[und][0][value][year]'] = '2011';
      $edit['field_test[und][0][value][month]'] = '15';
      $edit['field_test[und][0][value][day]'] = '49';
      $edit['field_test[und][0][value][hour]'] = '10';
      $edit['field_test[und][0][value][minute]'] = '30';
    }
    elseif ($options == 'text') {
      $edit['field_test[und][0][value][date]'] = '15/49/2011 - 10:30';
    }
    elseif ($options == 'popup') {
      $edit['field_test[und][0][value][date]'] = '15/49/2011';
      $edit['field_test[und][0][value][time]'] = '10:30';
    }
    $this->drupalPost('node/add/story', $edit, t('Save'));
    // This will currently fail since the type says "Test node has been created" 
    // But we should really reject such dates, right?
    $this->assertText($edit['body[und][0][value]'], 'Improperly formatted date. Please enter as ' . $date_format);
  }

  public function testFieldUI() {
// all this part is same as original . . .
    // Attempts to create text date field stored as a date with default settings (from input which is not valid).
    $this->createDateField($type = 'date', $widget = 'date_text');
    $edit = array();
    $this->drupalPost(NULL, $edit, t('Save field settings'));
    $this->malFormedDate($options = 'text');
    $this->assertText('Date does not match expected format.', 'Correctly failed to create invalid date.');
    $this->deleteDateField();

Forgot to change the status back to "active".

BTW (just to be clear) the "patch" file does not "fix" anything, but simply adds a basic test to demonstrate the primary issue described here.

Great, KarenS, and thank YOU. I just realized that hours and minutes also "roll over". 28:95 gets interpreted as 05:35 (the next day). I hadn't tested hours and minutes since they fall outside the granularity of our current use case (what we were initially testing), but just thought to add that to the date.test, too. I don't know if you've also improved validation for the "time" part?

Anyway... If you've committed a new test file to the module, I can see if I can find a way to break it tomorrow night when I get back from work (time to sleep now).

Oh... The other thing I noticed is that even if YYYY is specified for the year part, it accepts 2-digit entry for the year, but '11 is interpreted as 0011, which might not be what a user had in mind.

Hi Karen. Things seem to be working great now -- also with our local tests for our use case involving DD/MM/YYYY-format dates.

I've added a couple more test cases to your validation. One passes (you already have appropriate validation for the hour/minute values). The other, involving 2-digit entry for the year, does not yet pass (PHP seems to left-fill with zeros, which for most use cases would not be what the user has in mind, I'd think.) In any case, if the user doesn't enter 4 digits when that is the expected format, the module's validation should probably reject the entry, right?

I've attached a patch to add those tests. :-) (And a screenshot to give you a quick preview of the verbose message for the 2-digit year issue).