Closed (duplicate)
Project:
Date
Version:
6.x-2.8
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Jan 2011 at 19:27 UTC
Updated:
22 Jan 2012 at 23:28 UTC
Jump to comment: Most recent file
In 2.6 and previous when entering Multi Day All Day Events I simply left the time empty on both days and the all day event was correctly recognized. In the current 2.7 and dev versions these events are not recognized as All Day events and the time shows as 12:00am after each day. The attached screen shots are against a fresh install. I'm running PHP 5.2.13 and I've gone through the troubleshooting steps.
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | fix_multi_all_day_events-1013662-23.patch | 493 bytes | dperdue |
| #24 | fix_multi_all_day_events-1013662-24.patch | 489 bytes | dperdue |
| #15 | date_api.module.patch | 446 bytes | dperdue |
| #9 | date.theme_date_all_day.patch | 687 bytes | maddentim |
| AllDayMultiDay.jpg | 39.15 KB | dperdue |
Comments
Comment #1
zoltán balogh commentedFix it as soon as possible, please.
Comment #2
lukebrooker commentedI am having the same problem.
Comment #3
Morn commentedSame Problem (Date 6.27 and Drupal Version 6.20)
Comment #4
penguin25 commentedI've been looking into something similar to this on my site since upgrading to 6.x-2.7. I don't have any multi-day events, but I do have events running from 00:00 to 23:59 that were previously being displayed as "All day", but are now shown as 00:00 - 23:59.
For me, the problem occurs in a View that is displaying a date/time with a different granularity to the granularity of the underlying field. I haven't got a full solution yet, but it looks like it's related to the addition of the new "date_is_all_day()" function in date_api.module, and the subsequent changes to various other bits of code to use this function instead of trying to work out whether or not something is all day in an ad-hoc fashion.
In particular, if you look at the function theme_date_all_day() in date/date.theme in the old 6.x-2.6 release, you can see that it worked out whether something was all day or not using the granularity of the $format variable. But in 6.x-2.7, theme_date_all_day() calls date_field_all_day(), which in turn calls date_is_all_day(). If you follow this sequence of calls through, you can see that $format gets dropped, and the granularity is calculated from $field['granularity'].
On my site, the date fields have a granularity of seconds, but are displayed in a View with a granularity of minutes. So if:
then you can see why the behaviour has changed from 6.x-2.6 to 6.x-2.7. I think, although I haven't read the issue in detail, that it's similar to #447728: "All day" nodes are not detected as such because of the granularity of the Date field in the Calendar module.
Unfortunately I don't have time to work on this any more. I've come up with a workaround that is simply to explicity set $granularity to 'minute' at the start of date_is_all_day(), and ignore the value that is passed in. This works for me because my site always display dates with a granularity of minutes, but obviously it won't work for everyone.
I hope these comments can point somebody else in the direction of a proper fix.
Comment #5
fonant commentedFWIW I get this problem too.
Comment #6
gtaylor commented+1 we have the same issue
Comment #7
kassissieh commentedAwkward, temporary workaround: modify the final else statement to remove 12:00am in multi-day, all-day date displays (add to your template.php file).
Comment #8
Morn commentedNice Quick & Dirty, I applied it directly to date.theme (in date/date) using "- 00:00" because of 24 hours format
Comment #9
maddentim commentedThe problem is an if condition in theme_date_all_day() that uses = (for assigning value) instead of ==(for comparison). Here is a patch that solves it on mine. Please apply and test. Should work on 2.7 release. computers are so literal.
Comment #10
maddentim commentedComment #11
penguin25 commentedI don't agree with the patch in comment 9. The line mentioned there is testing the return value of date_field_all_day(), and simultaneously assigning the result into $all_day. This is the first time that $all_day has been written to, so using it in a comparison instead can't be right.
Comment #12
guusbosman commented+1 subscribe
Comment #13
ron collins commentedsubscribe
Comment #14
wotaber commentedsubscribe
Comment #15
dperdue commentedIn date_api.module on line 2679 inside the function
date_is_all_daythere's this block of code:which automatically makes events with different start and end dates not be recognized as All Day events. If you remove the last assertion in
ifstatement then it looks like this:and it works for All Day, Multi-Day events. I'm not sure the reasons why that assertion was there in the first place.
I've attached a patch.
Comment #16
ron collins commentedthe patch failed for me on 2.7 but i made the change manually and i now see "all day" as expected. i can't vouch for why the removed code was there in the first place. Thanks!
Comment #17
dperdue commentedThe patch is against the current dev release.
Comment #18
niek_kloots commentedDate 6.x-2.7
Calendar 6.x-2.4
Views 6.x-2.12
After applying the patch #15 the time in a multi-day event 0:00 is replaced with 'All day'
example:
Monday, 18 April, 2011 (0:00) - Tuesday, 19 April, 2011 (0:00) - old view
Monday, 18 April, 2011 (All day) - Tuesday, 19 April, 2011 (All day) - new view
Thanks for the patch. This looks better.
Comment #19
maddentim commented@penguin25 #11
Good point. Sorry not to have seen this in a bit. Got swamped.
However, it worked as I needed it to after I made the change.
Looking closely I see that, in the end, date_field_all_day() always returns either a TRUE or a FALSE and thereby could drive the if condition. While it is the first time $all_day is written to, it also seems to be the last as it is not used again in this function or returned so wouldn't it be better to just do?
Seems like a waste of memory to assign $all_day to memory.
Comment #20
osopolarThe patch in #15 failed for 2.7, it's late and so I don't see why. But as #16 I've made the change manually and "(all day)" is back.
Comment #21
developer-x commentedI've verified the change in #15. It's a good fix. I've committed the fix to 6.x-2.x and 7.x-2.x
Comment #23
dperdue commentedSee next comment.
Another patch that applies against the 6.x-2.7 release for Drush Make purposes.
Comment #24
dperdue commentedNevermind above, this is a patch that will work with Drush Make against 6.x-2.7
Comment #25
marktheshark commentedSorry for reviving this thread, but how do you make Date allow the storing of events without time-of-day in order to create all day events, when the granularity includes minutes?
I keep getting 'invalid date' and I'm unable to store the node...
Comment #26
modiphier commentedHello,
I have made the change to date_api.module as listed in comment #15 but when I add an all day event it displays a default time of 7:00pm I have date 6.x-2.7 what am I missing why is a default time still appearing. Do I need to flush anything after making the change to the .module file.
Start: Monday, September 3, 2012 7:00 pm
Thanks,
Paul
Comment #27
modiphier commentedJust uploaded the date-6.x-2.8 and I am still getting a default time of 7:00pm for an all day event? Any ideas or fix for this yet??
Thanks,
Paul
Comment #28
arlinsandbulte commentedThe patch in #24 of #1017216: custom date format without time shows "all day" should take care of this problem.
Please check that out and provide feedback if needed.
Thanks,