When creating Date field with To date as optional, I set "Default value for To date" to Blank. All correct, when I create the node, the value is blank. But immediatelly when you save it, From: value is filled in.

I think that Blank should stay blank - no value at all.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

masande’s picture

Version: 6.x-2.2 » 6.x-2.x-dev

i can confirm this bug with the dev version, too. the problem is exactly as the original poster describes – by leaving the optional 'to' date blank, it is populated by drupal with the 'from' date. i'd really like it if the blank field remained blank.

masande’s picture

Status: Active » Needs review
FileSize
968 bytes

i think i have figured this out. in order for date_elements.inc to perform validation on fields with both a from and to value, the $to_date is set to match $from_date even if the $to_date is left blank. what i have done to remove the $to_date (if that field is marked as optional) is to NULL $item[$to_field] is $from_date == $to_date. i don't think this will be a problem since if both dates match that means there the 'to date' field has not been optionally set.

i've attached a patch. please be kind since this is the first patch i've ever contributed.

nsciacca’s picture

The only I dislike about this patch is that it assumes that if the dates are equal that they were set by the system and the to value should be cleared. You should flag line 480 where it sets the "$to_date = $from_date;" when in the else of "if (!empty($field['todate'])) {" and then blank out the "to_date" later on if the flag was set. This is what I did, seems to work, not going to make a patch just yet....

(line numbers approximate.... sorry)

line 481
$from_date = date_input_value($field, $element[$from_field]);
if (!empty($field['todate'])) {

// Nsciacca: adding flag here.. I'm going to clear out the to value if it was forced
$tofieldelement = $element[$to_field];
$field_name = $tofieldelement['#field']['field_name'];
$postvalues = $element['#post'][$field_name];
if ($postvalues[$tofieldelement['#delta']]['value2']['date'] == '' ) {
$forced_to_date = TRUE;
}

$to_date = date_input_value($field, $element[$to_field]);
}
else {
$to_date = $from_date;
}

....

line 544
if (empty($errors)) {
// Nsciacca: if we flagged the date, clear it out
if ($forced_to_date) $item[$to_field] = '';
form_set_value($element, $item, $form_state);
}

arlinsandbulte’s picture

I marked #427772: To Date showing incorrectly in Preview/Edit as a duplicate of this issue.

I agree that an optional "to date" should remain blank.
I also agree with nsciacca that assuming that if the dates are equal that they were set by the system and the to value should be cleared is the wrong approach. There are instances when I WANT to fill in the from and to dates with the same value.

Nsciacca's logic above looks right to correct the issue (I have not tested it), but I think this may also be the wrong approach.
Instead of doing all this extra work & overhead to let the "to date" get set and then later blank it out, why not just change it so the optional "to date" never gets filled in?

LinL’s picture

@arlinsandbulte Thanks for picking up my issue #427772: To Date showing incorrectly in Preview/Edit and for the heads up about the latest version.

A quick update to my earlier issue report.

I stated that an optional blank to date is populated with the from date in the preview/edit page, but it is saved correctly. I should have said that it is shown correctly when the node is saved, but the database fields field_name_value and field_name_value2 are saved with the same date (the from date). As I only use the dates in a generated node title, built from date tokens, I've got round the bug, but I'd agree that it is a bug and optional blank to dates should remain blank.

LinL’s picture

drj8022’s picture

I've encountered this issue as well (To date not staying blank). Running Drupal 6.6. Tested Date 2.2, Date 2.3, and the -dev versions of the module all experienced this issue. Adding the patch to 2.3 fixed the date not staying blank problem. But there is another bug as well.

-- Still Grabbing From Date --
I created a custom content type to describe some projects I'm working on. I want to show site visitors a listing of all my projects, sortable by "Node:title" or "Date:to". I created a new view, add node title field, add active dates field, format active dates to "Display to date only", set view style to 'table", made the columns sortable, and selected the date field as the default sort. When I browse to the view, dates are wrong. If "Date:to" is blank, dates are displayed as "Date:from" and sorted thusly. Other dates display normally.

We think it's an issue of the Date module being unable to differentiate between "Date:to" and "Date:from" when you're in the view style settings. (eg.. change style to "table", click the gear, the options list only shows "date" under field and column.) This should not be the case, as my field is field_active_dates, and has been formatted to "Display to date only".

Any suggestions for a patch or workaround?

Extreme thanks in advance!

drj8022’s picture

Using this workaround for now:

1. Entering a "to date" in the future.
2. Created several theme overrides to display future dates as 'ongoing' sitewide.

Thanks!

marcushenningsen’s picture

By coincidence I just found out that this (on my machine) is related to the devel_themer module. Can I anyone confirm this? If you're experiencing this issue, try to disable the devel_themer module and see if it disappears.

Marcus

Anonymous’s picture

I'm encountering the problem as well and I don't use the devel_themer module marcus, so it might be related, but it wouldn't be only that relation. I'll test the solution suggested by nsciacca (http://drupal.org/node/523218#comment-1875950)

edit: I must admit though, it doesn't show the to-date in my views etc if I didn't set it myself. I'm perfectly happy with that, since I don't expect my data to change a lot (seminars and events like that usually don't change dates or names).

ssemigr’s picture

subscribing

BrightBold’s picture

Subscribing. Same problem.

philipperen’s picture

Version: 6.x-2.x-dev » 6.x-2.4

I confirm Marcus, in a view my date field passed from "19/12/2009 - 19/12/2009" to "19/12/2009" when I disabled the Theme developer module. I must add I experimented this double date problem even though my "To date" option in "Manage fields" was configured to "Never".

Internetter’s picture

Version: 6.x-2.4 » 6.x-2.x-dev
FileSize
403 bytes

I have another patch for this bug. I have used the latest dev-Version:
6.x-2.x-dev from 2009-Nov-11

Since it is also a flag $to_date_empty for an empty to-date, look at line 441:

  elseif (!form_get_errors()) {
                
    // Check todate input for blank values and substitute in fromdate
    // values where needed, then re-compute the todate with those values.
    if ($field['todate']) {
      $merged_date = array();
      $to_date_empty = TRUE;
      foreach ($posted[$to_field] as $part => $value) {
        $to_date_empty = $to_date_empty && empty($value);
        $merged_date[$part] = empty($value) ? $posted[$from_field][$part] : $value;
        if ($part == 'ampm' && $merged_date['ampm'] == 'pm' && $merged_date['hour'] < 12) {
          $merged_date['hour'] += 12;
        }
        elseif ($part == 'ampm' && $merged_date['ampm'] == 'am' && $merged_date['hour'] == 12) {
          $merged_date['hour'] -= 12;
        }
      }

The patch is only changing one line later in line 522:

      if ($test_to != date_format($to_date, 'r')) {
        $errors[] = t('The To date is invalid.');
      }
      if (empty($errors)) {
        if ($to_date_empty) $item[$to_field] = '';   # LINE INSERTED
        form_set_value($element, $item, $form_state);
      }
    }
  }
vincetingey’s picture

6 months and no fix yet? This problem is a BIG usability issue for us and simply doesn't make sense that if you leave an optional field empty that it would get auto filled.

neilnz’s picture

I tried out the patch from #14 but it caused an SQL error on Postgres because I'm using the datetime type (which uses real database timestamps) and it tried to write an empty string as a date, which Postgres refused to accept.

I've slightly altered the patch to set it to null instead of an empty string, and it then writes and works as I'd expect.

Revised patch attached.

tribe_of_dan’s picture

These patches don't seem to work with the latest dev (10 March 2010). Can anyone help?

Azol’s picture

Subscribing.

ycimlynn’s picture

subscribing

litzastark’s picture

subscribe

aegagros’s picture

I have the same problem! I have a calendar view and I only want to show events that last a single day (date-to-field blank) because several day lasting events just reappear every day in the calendar. Is there another way to filter out those apart from testing whether the "to" field is blank?

AdrianB’s picture

Subscribing.

pgillhaus’s picture

subscribing

enkara’s picture

subscribing

My problem is that I want to show nodes that are only between the two dates, but there can be nodes without expiration and now it's impossible to know if thwy only last one day or have no expiration

anonymous07’s picture

Version: 6.x-2.x-dev » 5.x-2.8

subscribe. Having a strange date issue with CCK date field being set to today's date on Node Import ... no matter what value I put in the override for that field; screwing up Scheduled Unpublish of nodes; causing them to unpublish at midnight the same day.

This issue literally just popped up out of nowhere.

Hoping to see if any of these threads are related or may give me clues. Thanks

arlinsandbulte’s picture

Version: 5.x-2.8 » 6.x-2.x-dev
Drupal Jedi’s picture

subscribing

YK85’s picture

I applied the patch and got this error output:

can't find file to patch at input line 7
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|:100644 100644 f188292... 0000000... M sites/all/modules/date/date/date_elements.inc
|
|diff --git a/sites/all/modules/date/date/date_elements.inc b/sites/all/modules/date/date/date_elements.inc
|index f188292..5b6fc19 100644
|--- a/sites/all/modules/date/date/date_elements.inc
|+++ b/sites/all/modules/date/date/date_elements.inc

Can anyone please help apply this patch to the latest 6.x-2.x?
Thanks!

soxofaan’s picture

Subscribing too (confirmed with CVS checkout from today)

related issue: "from" date is left empty, but "to" date is set: after saving both are empty

robby.smith’s picture

+1 subscribing - any updates on this?
Regards

YK85’s picture

Can someone re-roll the patch so it applies to 6.x-2.x? Thanks!

Cyberwolf’s picture

Subscribing.

prifel’s picture

Subscribing. This issue still exists with table views. Displaying To Date Only gives the from date when the to date is blank. Using Drupal 6 with latest dev version of Date and 2.11 of Views.

Cyberwolf’s picture

I confirm that the patch at #16 works as intended here. If the to date is intentionally left empty, it stays empty.

arlinsandbulte’s picture

Note: this issue is also present in the D7 version of date.
So, I created a separate issue for D7 here: #874322: To Date & All Day Date Handling

Hopefully, the D7 fix there will be able to be back ported to D6 here.

YK85’s picture

Status: Needs review » Reviewed & tested by the community

The patch looks to fix the issue (but had to manually apply it).

KarenS’s picture

Status: Reviewed & tested by the community » Needs work

The current behavior is 'by design' -- dates with option 'to' dates get filled in with the 'from' date. The problem is that making the 'to' date blank isn't the only issue, or even the most important one. The most important issue is whether those dates with empty 'to' dates will create problems elsewhere, since the current code has made lots of assumptions about a value being present.

To test this well enough for me to commit it, you have to not only see if the widget displays the way you want, but also run around and try to do lots of things with those dates -- add them to views, use them in filters and arguments, generally bang the heck of them to see if anything else breaks.

tribe_of_dan’s picture

Hi KarenS, thanks so much for all the great work you've done on this module.

As a suggestion, how to you think blank dates would be affected if 'to' dates defaulted to todays date? Or if there was a switch between defaults being 'Same as from date' OR 'Todays date' (as determined by site settings). How do you think a change like that would go?

Cyberwolf’s picture

FileSize
611 bytes

Attaching rerolled patch from #16 that should cleanly apply on 6.x-2.x.

ZeiP’s picture

Patch in #39 fixed this for me.

Dane Powell’s picture

FileSize
741 bytes

Here's an updated patch, rolled with git against the latest 6.x-2.x. I know it might not be the best solution, like KarenS mentioned, but it's working for me and obviously others as well.

Dane Powell’s picture

FileSize
316 bytes

Here it is again, WRT 6.x-2.7 (since #41 won't apply cleanly to 6.x-2.7)

Azol’s picture

Status: Needs work » Needs review
suffering drupal’s picture

Hi all! Are you aware there is another "blank should stay blank" issue?
If you use date in a user's profile field for date of birth (through content profile) and you make it required then the following happens.
First time on the page, all the date fields are blank. If user does not fill out then you get a warning it is required. BUT when you get back to the sign-up page for the second time, the fields ARE filled out, with the first option for each dropdown, so it's all january first and then the "oldest" year you defined (-50 for example would give 1961).
And then the user CAN finish the sign-up without touching the date.

The reason that I tried this option (content profile + date) is because the date in the original CORE profile module, directly gets filled out with the date of TODAY. So required there doesn't even make sense. And if people sign up that way, they are all born TODAY. Same problem goes for additional fields you want to be required on signup, eg: country or gender.

I have been searching for several days now, but is seems that Drupal simply does not count with a standard BLANK FIELD option (that stays blank) to make filling out really "required". I'd say this si pretty important...

Any suggestions? (no coding or hooks or patches though, just plain out of the box possibilities, or do they not exist?)

NancyDru’s picture

Another use case: Think of a resume. You're still at your current job, i.e. the "to" date is blank when you add the job; you need it to stay blank. [Actually, I'd rather it be "now" and stay "now", even in Views.] So then you want to sort it (desc) in Views. Oops! I guess I have to look into some kind of Views sort handler... Yuck.

Encarte’s picture

Subscribing

Nor4a’s picture

I used the patch #42 - it works, but still want to see this in the stable version...

wusel’s picture

subscribing for D7 without CCK.

The same issue while importing using Feeds or Migrate.
An empty input-field '' or 0 or NULL in the CSV-file must show an empty field in the database.

Until now after import the field shows the date of the import and not an empty field.

mnsweeps’s picture

Wusel

I am using xml_parser to import xml into Drupal. The date field in xml is '' and I expect the value in Drupal database to be blank or null. However it defaults to the IMPORT date or current date / time when the import happened ? any fix for this ?

arski’s picture

Component: Date CCK Field » Code

any chance of this getting committed soon? I think this can be marked as reviewed and tested by the community already, or?

jaxxed’s picture

There is an outstanding question with this patch:

Should the blank value be stored in the db, or presented at display/edit time as blank?

The following a few points to consider:

  • can we rely on the 'to==from' means that the to date is blank approach?
  • The db blank value works for some db cases, but apparantly causes a view issue (blank values won't filter properly.) (mentioned above)
  • The blank on presentation value doesn't work with some db cases (postgres is mentioned above.)

It seems to me that:

  • date validation for non-required individual field items should allow blank values, meaning that we don't need this 'to==from'
    consideration;
  • the blank value should be viable for all db values (if it allows null);
  • the date views integration should be responsible for handling missing optional values (using the allow null values checkbox makes sense for filters);

These questions need to be decided upon before the approach suggested can be followed. What am I missing in these lists?

EDIT - removed my comments about the above patches

KarenS’s picture

The blank value cannot be stored in the database without requiring a complete rewrite of all the Date code. That is not an option.

wusel’s picture

Can you add an NaD-value ("Not a Date") to the date module? NaD may be stored as the first second of the technical possible values of the date-field as an constant.

This or a blank value or something else is neded to show, that a birthday-field has no value, if we don't know the date of the birthday of a member or user.

Thank you very much.

Dane Powell’s picture

FileSize
499 bytes

#42 updated for 6.x-2.8. Still has the issue mentioned in #51.

robertgarrigos’s picture

I'm having a similar problem which might be the same: A required date field with a default value to "today" becomes empty it form doesn't validate. This is, if the node form has to be shown again because some other field validation problem, the required date field doesn't get populated with the today's date.

My problem looks like this other (http://drupal.org/node/1399728). Are they duplicated of this one here?

standingtall’s picture

Version: 6.x-2.x-dev » 7.x-2.1

Same issue

arlinsandbulte’s picture

Version: 7.x-2.1 » 6.x-2.x-dev

This issue is for the D6 version.
Here is the D7 issue: #874322: To Date & All Day Date Handling

mikedotexe’s picture

#54 worked for me, and we really, REALLY needed it. thank you
by the way, to deal with views I've included a query hack that may be helpful to others. Here we're trying to see the range of someone's employment.
If someone has an EMPTY "To Date" then they're considered ongoing.

Here we have exposed filters searching date ranges.

function mymodule_views_query_alter(&$view, &$query){
	dsm($query, 'query');
	if ($view->name == 'my_view_name'){
		$original = $query->where['date']['clauses'][0];
		$query->where['date']['clauses'][0] = '(node_field_event_date.field_event_date_value2 IS NULL OR ' . $original .')';
	}
}
smithwib’s picture

Does #54 resolve #44?

varr’s picture

After testing it myself, #54 does NOT resolve #44.

varr’s picture

After doing some additional testing a few things became clear.

  1. The faulty dates only show up in the fields AFTER the first save ... not during the initial node creation.
  2. The faulty dates are populated during the second page load form creation and NOT from database content. i.e. the dates had not been saved in the database yet and were being randomly generated during the form creation.
  3. The faulty dates are randomly populated ... some fields get them, some don't, even when all the date fields have been set up the same.

This tells me that the real problem is happening during the second page form creation NOT during the form validation or submission.

Ouach’s picture

Subscribing.
Thanks.

BrightBold’s picture

@Ouach — Stop subscribing, start following! (Use the Follow button in the upper right.)

ouelmart’s picture

Issue summary: View changes

this issue has been up for 5 years. the code of line works. why is this not yet in a release??

roi’s picture

Any news on that? I am on Drupal7 and still NULL disappears from my FIELD_value2 column after I save the entity, and another date replaces it.

W.M.’s picture

Seems this never was resolved for Drupal 7

DamienMcKenna’s picture

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

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.

arun.mytimez’s picture

This issue is still persisting in D7 version. I have a to field that is having NULL value, but when showing this value in a view, its having the same value as the from field. I checked the db table and the value2 is holding value NULL, but its the view render that displays the value as the same from value.

arun.mytimez’s picture

Version: 6.x-2.x-dev » 7.x-2.10
Status: Closed (won't fix) » Active
arlinsandbulte’s picture

Version: 7.x-2.10 » 6.x-2.x-dev
Status: Active » Closed (won't fix)

There is a separate issue for D7 here:
#874322: To Date & All Day Date Handling

DamienMcKenna’s picture

Thanks @arlinsandbulte. Going to add it as a related issue to help others find it.