Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#54 | date-523218-54.patch | 499 bytes | Dane Powell |
#42 | date-523218-42.patch | 316 bytes | Dane Powell |
#41 | date-523218-41.patch | 741 bytes | Dane Powell |
#39 | date_523218.patch | 611 bytes | Cyberwolf |
#16 | date_elements.inc_.nullto.patch | 616 bytes | neilnz |
Comments
Comment #1
masande CreditAttribution: masande commentedi 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.
Comment #2
masande CreditAttribution: masande commentedi 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.
Comment #3
nsciaccaThe 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);
}
Comment #4
arlinsandbulte CreditAttribution: arlinsandbulte commentedI 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?
Comment #5
LinL CreditAttribution: LinL commented@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.
Comment #6
LinL CreditAttribution: LinL commentedI've also marked #483456: Renders CCK-date-fields with To date even though none is given as a duplicate.
Comment #7
drj8022 CreditAttribution: drj8022 commentedI'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!
Comment #8
drj8022 CreditAttribution: drj8022 commentedUsing 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!
Comment #9
marcushenningsen CreditAttribution: marcushenningsen commentedBy 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
Comment #10
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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).
Comment #11
ssemigr CreditAttribution: ssemigr commentedsubscribing
Comment #12
BrightBoldSubscribing. Same problem.
Comment #13
philipperen CreditAttribution: philipperen commentedI 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".
Comment #14
Internetter CreditAttribution: Internetter commentedI 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:
The patch is only changing one line later in line 522:
Comment #15
vincetingey CreditAttribution: vincetingey commented6 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.
Comment #16
neilnz CreditAttribution: neilnz commentedI 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.
Comment #17
tribe_of_dan CreditAttribution: tribe_of_dan commentedThese patches don't seem to work with the latest dev (10 March 2010). Can anyone help?
Comment #18
Azol CreditAttribution: Azol commentedSubscribing.
Comment #19
ycimlynn CreditAttribution: ycimlynn commentedsubscribing
Comment #20
litzastark CreditAttribution: litzastark commentedsubscribe
Comment #21
aegagros CreditAttribution: aegagros commentedI 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?
Comment #22
AdrianB CreditAttribution: AdrianB commentedSubscribing.
Comment #23
pgillhaus CreditAttribution: pgillhaus commentedsubscribing
Comment #24
enkara CreditAttribution: enkara commentedsubscribing
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
Comment #25
anonymous07 CreditAttribution: anonymous07 commentedsubscribe. 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
Comment #26
arlinsandbulte CreditAttribution: arlinsandbulte commentedComment #27
Drupal Jedi CreditAttribution: Drupal Jedi commentedsubscribing
Comment #28
YK85 CreditAttribution: YK85 commentedI applied the patch and got this error output:
Can anyone please help apply this patch to the latest 6.x-2.x?
Thanks!
Comment #29
soxofaan CreditAttribution: soxofaan commentedSubscribing too (confirmed with CVS checkout from today)
related issue: "from" date is left empty, but "to" date is set: after saving both are empty
Comment #30
robby.smith CreditAttribution: robby.smith commented+1 subscribing - any updates on this?
Regards
Comment #31
YK85 CreditAttribution: YK85 commentedCan someone re-roll the patch so it applies to 6.x-2.x? Thanks!
Comment #32
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #33
prifel CreditAttribution: prifel commentedSubscribing. 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.
Comment #34
Cyberwolf CreditAttribution: Cyberwolf commentedI confirm that the patch at #16 works as intended here. If the to date is intentionally left empty, it stays empty.
Comment #35
arlinsandbulte CreditAttribution: arlinsandbulte commentedNote: 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.
Comment #36
YK85 CreditAttribution: YK85 commentedThe patch looks to fix the issue (but had to manually apply it).
Comment #37
KarenS CreditAttribution: KarenS commentedThe 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.
Comment #38
tribe_of_dan CreditAttribution: tribe_of_dan commentedHi 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?
Comment #39
Cyberwolf CreditAttribution: Cyberwolf commentedAttaching rerolled patch from #16 that should cleanly apply on 6.x-2.x.
Comment #40
ZeiP CreditAttribution: ZeiP commentedPatch in #39 fixed this for me.
Comment #41
Dane Powell CreditAttribution: Dane Powell commentedHere'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.
Comment #42
Dane Powell CreditAttribution: Dane Powell commentedHere it is again, WRT 6.x-2.7 (since #41 won't apply cleanly to 6.x-2.7)
Comment #43
Azol CreditAttribution: Azol commentedComment #44
suffering drupal CreditAttribution: suffering drupal commentedHi 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?)
Comment #45
NancyDruAnother 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.
Comment #46
Encarte CreditAttribution: Encarte commentedSubscribing
Comment #47
Nor4a CreditAttribution: Nor4a commentedI used the patch #42 - it works, but still want to see this in the stable version...
Comment #48
wusel CreditAttribution: wusel commentedsubscribing for D7 without CCK.
The same issue while importing using Feeds or Migrate.
An empty input-field
''
or0
orNULL
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.
Comment #49
mnsweeps CreditAttribution: mnsweeps commentedWusel
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 ?
Comment #50
arski CreditAttribution: arski commentedany chance of this getting committed soon? I think this can be marked as reviewed and tested by the community already, or?
Comment #51
jaxxed CreditAttribution: jaxxed commentedThere 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:
It seems to me that:
consideration;
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
Comment #52
KarenS CreditAttribution: KarenS commentedThe blank value cannot be stored in the database without requiring a complete rewrite of all the Date code. That is not an option.
Comment #53
wusel CreditAttribution: wusel commentedCan 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.
Comment #54
Dane Powell CreditAttribution: Dane Powell commented#42 updated for 6.x-2.8. Still has the issue mentioned in #51.
Comment #55
robertgarrigos CreditAttribution: robertgarrigos commentedI'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?
Comment #56
standingtall CreditAttribution: standingtall commentedSame issue
Comment #57
arlinsandbulte CreditAttribution: arlinsandbulte commentedThis issue is for the D6 version.
Here is the D7 issue: #874322: To Date & All Day Date Handling
Comment #58
mikedotexe CreditAttribution: mikedotexe commented#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.
Comment #59
smithwib CreditAttribution: smithwib commentedDoes #54 resolve #44?
Comment #60
varr CreditAttribution: varr commentedAfter testing it myself, #54 does NOT resolve #44.
Comment #61
varr CreditAttribution: varr commentedAfter doing some additional testing a few things became clear.
This tells me that the real problem is happening during the second page form creation NOT during the form validation or submission.
Comment #62
Ouach CreditAttribution: Ouach commentedSubscribing.
Thanks.
Comment #63
BrightBold@Ouach — Stop subscribing, start following! (Use the Follow button in the upper right.)
Comment #64
ouelmart CreditAttribution: ouelmart commentedthis issue has been up for 5 years. the code of line works. why is this not yet in a release??
Comment #65
roi CreditAttribution: roi commentedAny 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.
Comment #66
W.M. CreditAttribution: W.M. commentedSeems this never was resolved for Drupal 7
Comment #67
DamienMcKennaUnfortunately 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.
Comment #68
arun.mytimez CreditAttribution: arun.mytimez as a volunteer commentedThis 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.
Comment #69
arun.mytimez CreditAttribution: arun.mytimez as a volunteer commentedComment #70
arlinsandbulte CreditAttribution: arlinsandbulte as a volunteer commentedThere is a separate issue for D7 here:
#874322: To Date & All Day Date Handling
Comment #71
DamienMcKennaThanks @arlinsandbulte. Going to add it as a related issue to help others find it.