Submitting date fields returns error "Field X is invalid"

Same thing is happening to me after updating to 6.x.2.10.

This is a BIG problem because no new content that uses date can be created, nor can existing content be updated.

update... my field settings are pretty much identical to parents:

widget type: text field with custom input format
default value: blank
default value for To date: same as From date
Input format: 2014-04-24 13:01:01
Custom input Format: Y
Required? no
Number of values: 1
To Date: Never
Granularity: Year only
Default Display: custom created to only display year
time zone handling: no time zone conversion

We are experiencing this as well. Our custom input format is "F j, Y" and the field is always flagged invalid when creating new content or editing old.

We reverted to 6.x.2.9 and it works again.

I was able to workaround this issue by changing the widget type to Select.

An update:

I checked some other date fields in use, and when the date has Y-M-D all used it validates just fine, but when it's using only Y or Y-M then it fails.

YMD field setup:
widget: text field with Date Pop-up calendar
input format: 2014-05-01
number of values: 1
to date: never
granularity: Year, Month, Day
No timezone conversion

YM field setup:
widget: text field with Date Pop-up calendar
input format: 2014-05-01
number of values: 1
to date: never
granularity: Year, Month
No timezone conversion

My Year only field settings are above in an earlier comment.

Switching the not-validating fields to 'Select' does indeed fix the issue. I expect it doesn't do any validation at all.

Same issue here.

I reverted back to 6.x-2.9.

Hi

I'm getting this as well. I'm keen to know how people reverted from 2.10 to 2.9. Did you just delete the module files and copy over the 2.9 files. Did you run update.php after that?

Cheers
Chris

I just did the reversion down to 2.9 and it is working fine. For anyone's interest, it seems that if you look in the .install file and there is NOT a hook_update function then there is no db update associated with the upgrade so you can safely revert. Happy to be corrected on this.

Same issue for me as well. I am going to try to revert. This was an issue in the past as well for this module.

Same issue for me with a "Y" field - reverted to 2.9 and that fixed it.

subscribe... :-(

same issue with Y and m/Y fields...

Core and all modules updated, all settings checked several times and still have no idea, what the problem may be.

Is reverting back to 2.9 really the only option?

Workaround confirmed: reverting 6.2.10 to version 6.2.9 fixes the problem for me as well. Drupal 6.31.

The field in question has a custom input format of just "Y". Granularity is set to "Year". Default display is "ISO".

Reverting to 6.2.9 is no option for me as that version reintroduces a bug which forces Views to use massive duplicate Left Joins on date fields (in some situations) resulting in Mysql server crashes. My shared hoster had a long weekend until he figured this out ;)

The bug was always in the code but now appears because this bug was fixed: #501416: Date validation incorrect for days > 31

Let's try the following patch.

Testing bug?

Another one.

I have no idea why this patch doesn't pass. Via simplytest.me it looks exactly like what the tests are expecting.
Can you please just review #17 (without the test-case rewrite)?

Same issue here. I'm using Y-m (Year-Month) format. My problem started when I updated FileField to 6.x.3.13 just a few days ago. Date field is at 6.x-2.10 and has been for a while. When I updated FileField, I also started experiencing problems with ImageField and attached documents. Those seem to have worked themselves out but I wonder if FileField plays a role in the Date problems.

Has anyone tried these patches? Do they work? I'd rather go with a patch then change my Date widget type to Select.

I have tried the path in #17 and it worked for us, thank you!

Patch in #17 worked for me as well.

Found the root cause of this issue.

1. #501416: Date validation incorrect for days > 31 tried to fix the problem of checking for valid date. I believe it is valid fix. However this condition was causing endless loop(even without #501416: Date validation incorrect for days > 31) and return FALSE. Endless loop goes in this order: date_is_valid=>date_valid_day=>date_days_in_month=>date_make_date=>date_is_valid.

2. date_limit_value() adjust the dates without month or year. So removed the date_is_valid condition entirely to get the data field. Not sure, if it produce any other regression.

Let's try this patch...

Did you find a problem with patch #17, vijaycs85? Curios how the changes in date_days_in_month() are helping?

Regarding the date_is_valid() condition in date_limit_value() I think it's to avoid unnecessary work in case the date is already valid.

Curios how the changes in date_days_in_month() are helping?

Well it has been wrong and root cause of this issue is because the change of date_valid_day($day, $month, $year) to !date_valid_day($day, $month, $year) in #501416: Date validation incorrect for days > 31.

Did you find a problem with patch #17

The problem with #17 is we don't want to return, if the date is valid. We want to return if it is invalid. However, like this case(just year), sometimes, we need to adjust invalid date as well. So I removed the date validation check.

We need to find the fails and make sure those cases are covered. I will try to fix them later today. Feel free if anyone want to jump in.

From the documentation of date_limit_value():

* Example:
* date_limit_value('2007-05-15 04:45:59', array('year', 'month', 'day'))
* returns '2007-05-15 00:00:00'

That said, we want the date returned immediately if it is
a) valid (2014-04-31 is not)
b) has no unnecessary date parts

When I think about it, the condition should look like this:

if (date_is_valid($date, $type, $granularity) && !$nongranularity = date_nongranularity($granularity)) {
    return $date;
  }

Untested ;)

thanks for the reference @haggins. It makes lot of sense. We had wrong condition and it was working fine until the fix in date_is_valid. Updating patch to reflect what we have in #17. Sorry for the confusion.

Also found that the test fails are nothing to do with this fix. We fixed these fails sometime back in 7.x and didn't port back to 6.x.

yay, green. would be great to have some reviews and manual test to this in. Thanks in advance :)

Looks good to me, thanks! Will be able to test it in 10-14 days.

Patch in #34 didn't work for me. I'm using granularity DD.YYYY. Only reverting to 6.x.2.9 helped me out.

xurubu93, can you give some details on what didn't work, please? Do you just get still validation errors or are there any other issues?

I'm getting the following message "Field X is invalid", so it's still regarding validation.

Same here, I am still getting error after applying patch in #34.
Only option is to use Select widget or revert to 6.x.2.9
Would be good to get a real fix for this though...

Same issue still with 6.x-2.10. I have a CCK date field that has a custom format of Y. This has been working for the past 5 years and now after upgrading to 2.10 I get 'A valid date is required for....'

Reverting back to 6.x-2.9 fixes the issue.

I sure hope that this can be fixed one day.

Applied patch #34 and seemed to have fixed the Y error I was getting but now I'm getting this error:

warning: Invalid argument supplied for foreach() in /public_html/sites/all/modules/date/date_api.module on line 1601

The problem is assigning $nongranularity in the if, assign before doing the if, and the error goes away. (Dont have the setup to produce patches atm.)

function date_limit_value($date, $granularity, $type = DATE_DATETIME) {
$nongranularity = date_nongranularity($granularity);
if (date_is_valid($date, $type, $granularity) && !$nongranularity) {
return $date;
}

Thanks peranet.

I can confirm that between the patch at #34 and the above patch to the date_api.module at #43, the issue is fixed and I can once again add a four digit year into the date field.

I now can use 6.x-2.10 YAY!!

I had the exact same problem than Katharine_Gates explained in the description.
#34 + #43 fixed the issue for me.
I didn't test other scenarios though but here is a reroll.

Thanks a lot everyone.

#45 applied cleanly and i can now save nodes that have a year granularity only.

Edit: I noticed that the error persists if you use the popup select widget.

Thanks

#45 applied and still having errors with invalid fields.

Details:
The widget type is Text field with custom input format (worked OK before)
Custom input format is set at 'd/m/Y'
Granularity is set to Day.

#45 works for me. I was seeing the same problem as the OP (a year-only field causing "a valid date is required" error on node edit).

#45 works for me
thanks

Setting this to RTBC .

#45 merged. Thanks