If date fields are read from a table and rendered using #type => 'date' , a value of '0000-00-00' in the field will cause the rendered date to be 1900-1-1. The following patch adds a key value of 0 in $options array of day,month and year i.e $options[0] = '--'; causing the date to be displayed as -- -- --.

CommentFileSizeAuthor
form.inc.patch_2.txt553 bytesdebdungeon
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drumm’s picture

Status: Reviewed & tested by the community » Needs review

This needs review.

Dries’s picture

Status: Needs review » Closed (won't fix)

I don't think this is a problem in forms.inc. It looks like a problem with the calling code ... you should provide such dates to the forms API.

debdungeon’s picture

Status: Closed (won't fix) » Needs review

This happened to me when using datetime fields in mysql. The value returned was '0000-00-00' which when rendered as $form['somedate'] = array('#type' => 'date', '#value' => array('day' => 0, 'month' => 0, 'year' => 0)) will result in 1900-01-01 as there is no key value of 0 in any of the selects.

drumm’s picture

Status: Needs review » Needs work

Instead of adding another option, can we have it go to today's date instead?

I think a new option needs consideration of things like validation. A required date field needs to have all of the values set.

(And the current convention for Drupal code is to use unix timestamps rather than SQL dates so format_date() may be used on output.)

Dries’s picture

I still think this should be marked "won't fix". If you want the current date, specificy the current timestamp.

debdungeon’s picture

But thats exactly my problem. There are a number of date fields like date_of_accident, date_of_bill etc. Some have valid values while others have value of '0000-00-00'. If the 0 key value is not present all date fields for which no specific date value is selected, will be updated to 1900-1-1 or current_date which would be incorrect.

The current cvs version has date_validate function which catches 0000-00-00 dates in case of required date fields.

I personally prefer unix timestamps but I happen to be working on a database provided by the client. I am just developing an interface around the db.

ricabrantes’s picture

Version: x.y.z » 7.x-dev

This bug is active??

sean.mtm’s picture

I'm looking at essentially the same issue but from a different angle - there's no way to have a null-value with the date selector. To see a case where this would be relevant, I'm making an input for an 'event'. An event may be a single day or it may span multiple days (thus having a start date & an end date). Start date is a required value but the end date is not - a null in the end date would indicate a single-day event.

With the current date input, there is no clear & unambiguous way of not entering a date.

Jaza’s picture

Title: Date displays incorrectly when date value is '0000-00-00' » FAPI date type doesn't support a null date value
Version: 7.x-dev » 8.x-dev
Category: bug » task

I agree that this issue is still relevant. @sen.mtm is right: there is no way to not enter a date with the current FAPI date processor.

BTW, expand_date() is now form_process_date().

Moving.

jhedstrom’s picture

Issue summary: View changes
Status: Needs work » Closed (works as designed)

Dates can be optional in the form API.