All day events

Thanks for the feedback - yes I will have it set the allDay option for the events if the time is empty.

Due to the way the date fields work, I decided the best option for creating allDay events was to determine which fields have hour and minute set in their granularity. Otherwise I couldn't find an easy way to determine if an event was supposed to be at midnight or all day. Beta2 will mark an event as allDay if the field as setup in CCK does not have hour (and thus minutes too) granularity selected.

With #2 implemented above, the way that Date determines 'All Day' and the way that FullCalendar module determines 'All Day' is different.
This can be very confusing for the end user when the node displays 'All Day' but the FullCalendar view does not.
Also this method forces the site to use different content types for an 'All Day' Event vs a milestone or time slot event.

I think (for now at least), FullCalendar should determine 'All Day' events the same way Date does:
For a date field with no To Date (To Date set to Never), it is labeled as "All Day" when the time equals 12:00AM.
For a date field with a To Date ('To Date' is set to Optional or Required), it is labeled as "All Day" ONLY when both the From Date & To Date times are on the same day AND both set to 12:00AM.

I realize this causes a problem when someone wants to set a milestone event with time at 12:00AM... it will show as 'All Day.' A work around is to give this event To Date (like 12:01AM or 1:00AM).

This is the way Date module works right now, and I think FullCalendar should respect that (even though it might be flawed).

See this discussion on different ideas to better solve this shortcoming by changing the Date module:
http://drupal.org/node/874322#comment-3317858

Here is a start to implement #3.
It does not work with timezone conversions, so it still needs work.

The date module does all it's timezone handling internally and occasionally in the theme layer, so it had to be replicated, instead of reused.

Ack. My patch is against HEAD, so I'm guessing that's closest to 6.x-1.2-beta2. The branches are a little messed up, and you should probably enable snapshot releases, at least for the issue queue's sake.

Patch in #5 works wonderfully with beta3!

http://drupal.org/cvs?commit=449392

I have the latest version of fullcalendar installed and I'm still having this issue. My nodes have no time element, just date, and I get the 12am (or 00:00) in the calendar. What version of fullcalendar was this patch committed to?

We're using date modules time handling, perhaps it doesn't take into account dates without time granularity. I will look into this.

perhaps it doesn't take into account dates without time granularity.

Correct, you can fix this by calling the deeper function directly.
The function is a little uglyer for D7 but it works.
The function we used is also wrong, cause they pass two times the same date ($date1) to the deeper function

See: http://api.lullabot.com/date_field_all_day
AND http://api.lullabot.com/date_is_all_day

WARNING :p
-----------
After reading those functions again I realise we have to use the D7 patch on all branches.
So don't use the D6 patch its wrong, as it passes a date object in stead of a date string...

Postponed on #1041428: Improper logic in date_field_all_day.

In reality, we might need to write our own date functions anyway.

D6 patch does not work, because date_is_all_day expects a string, not a date object. Try this one.

#14, yes aspilicious made that comment at the end of #12.

Both of these patches are wrong, because neither take into account granularity or increment.

However, there are logic choices in date_is_all_day that don't suit fullcalendar anyway, hence my comment in #13.

Thanks tim, sorry to be redundant.

I don't really understand #13 I guess. So far my version of the D6 patch works, including with drag & drop - what is the logic problem?

Neither patches include $granularity or $increment.
Try switching your date field to minute granularity with 15 minute increments. Be sure to edit the nodes so they get the right settings.
Then make one "all day", i.e. 00:00 - 23:45. It won't work with these patches.

Isn't it enough that they call date_is_all_day() ? That function checks both of those in its logic.

http://api.lullabot.com/date_is_all_day

#18, in order to call that function, we'd have to reimplement date_field_all_day anyway.
Also, the logic in date_is_all_day() doesn't work for all day events that span multiple days.

See my comment in #13.

Well it only checks for it when you pass it to the function. And we just use the defaults which is OK for most situations but it is not fool proof.

Yes, I see what you mean with the multiple day problem now. I will try to write a new function and post a new patch when I have something.

What if we JUST based the all day logic on field granularity? That would work for my use case, but not sure about others'.

dafeder, we're already trying to replace the calendar module, I'm not writing my own date module too.
I've filed issues and submitted patches to date module.

I'm postponing this issue for the short term. fullcalendar_date.module would be insanity.

tim, I understand and don't want to push this. For what it's worth, this patch has been working for me so far for 6.x. I'm not submitting this for inclusion, just posting in case others want to try it as well. It treats my nodes as all-day whenever the date field has day granularity.

Tired of seeing this in my bug tracker, since there is nothing I can do about it from outside Date module.

This was fixed in July.