Calendar Week view shows All Times and All Day

I have the same issue even after upgrading to 6.x - 2.2 and I am banging my head trying to figure it out too... When is "All day" applied and when is "All time" applied so that I can translate them consistently in french ?

Thanks!

same problem, help!

I have just upgraded to D6, and find that my "all day" events have this same problem. Here is what I found:
at line 522 in calendar/includes/calendar.inc

  if (date_format($node->calendar_start_date, 'H:i:s') == '00:00:00' && 
    date_format($node->calendar_end_date, 'H:i:s') == '23:59:59') {
      $node->calendar_all_day = TRUE;
  }
  else {
    $node->calendar_all_day = FALSE;
  }

Previously, a start time of '00:00:00' would indicate "all day", and since my items don't have end dates, I just commented out the second part of the if test. Now they show up in the week view as "all day".

There is probably a better way to do this, because I can see that under certain conditions, you might WANT an event to start at midnight and not last all day. Here is ONE slightly better way:

  if (date_format($node->calendar_start_date, 'H:i:s') == '00:00:00' &&  
     (date_format($node->calendar_end_date, 'H:i:s') == '23:59:59' || 
      date_format($node->calendar_end_date, 'H:i:s') == '00:00:00')) {
        $node->calendar_all_day = TRUE;
  }
  else {
    $node->calendar_all_day = FALSE;
  }

Note: it is also bad policy to change module code like this -- it will go away on the next update.

Here is an improvement:

  if (date_format($node->calendar_start_date, 'H:i:s') == '00:00:00' &&  
     (date_format($node->calendar_end_date, 'H:i:s') == '23:59:59' || 
       ($node->calendar_end_date == $node->calendar_start_date) ) {
        $node->calendar_all_day = TRUE;
  }
  else {
    $node->calendar_all_day = FALSE;
  }

I am worried about the logic of this - It still seems as perfectly legitimate to have an event that starts and ends at 12:00am as to have one that starts and ends at 12:01am, and I think that this is the design decision made in the calendar module. But this is not consistent with the date_api

The method above is consistent with the current cck + date modules' handling of from and to times: I created a test content type with a date field requiring 'from' and 'to' components. If I enter the start time as 12:00am and the end time of 12:00am, the content displays with '12:00am (All day)' If I set the end time to 12:01am, the content displays with '12:00am - 12:01am'. If I set the end time to 11:59pm, the content again displays with '12:00am (All day)'.

There is another problem with the logic in the module: A date with granularity less than 'seconds' will not be able to create the '11:59:59pm' time required to meet the test. If I try setting the 'to' time to 12:00am on the next day, I do get an All day event, but with another event at midnight on the next day.

[Sorry, this was supposed to be a reply to #2 ]

I was confused by your reference to "All times" because my calendars came up with 3 rows: "All day" then "Before 7:00pm" and "7:00pm". This was because I had 2 events in the week, one that was at 7:00pm and another that I thought was "all day" but failed the test (see my comment below). It appears that the module goes through all events for the week, and and creates a row for each time, but ignores '00:00:00'.

I have attached a snapshot of my calendar with just one event, going from 00:00:00 on 26 Jun to 00:00:00 on 27 Jun (see how it catches the all day and then creates an extra event). (alltimes.png)

Then I added another event at 8:00pm on 23 Jun and you see the change in the rows. (alltimes2)

Finally, I changed the granularity on the all day event and set its end time to 11:59:59pm on 26 Jun, and you see what I would expect (alltimes3)

Another suggestion for All day events:

If a "to" date is not equal to the "from" date and its time is "00:00:00", change the $to value to be one second earlier:

After line 446 of calendar/includes/calendar.inc:

// Catch a $values_display[1] that is midnight and not the same day as $now
if ( substr($values_display[1],11,8) == '00:00:00' && $to != $now ) {
  $new_end = date_convert($to,DATE_DATETIME,DATE_UNIX) - 1;
  $date2     = date_convert($new_end,DATE_UNIX,DATE_DATETIME);
  $to = min($max_zone_string[$display_timezone_name], substr($date2, 0, 10));
}   

(Sorry, I am not up on the date conversion process, that code could be cleaner, but you get the idea).

Now, if an event has a start time of 2009-06-26 00:00:00 and an end time of 2009-06-29 00:00:00, it will show up as an all day event on the 26th, 27th, and 28th, but not on the 29th. If your granularity is hours or minutes, this is what you would expect. I am afraid that if your granularity is days, this would not be expected.

Is there a way to know the granularity of the input dates? If they are CCK, I would guess so, if not...

Another code to get it working when using feed api to fetch an Ical Google calendar

if (date_format($node->calendar_start_date, 'H:i:s') == '00:00:00' &&
(date_format($node->calendar_end_date, 'H:i:s') == '23:59:59' ||
(date_format($node->calendar_end_date, 'H:i:s') == '00:00:00' && $node->calendar_end_date == $node->calendar_start_date) ) ) {

This looks like the same issue I was having, try my patch here - #447728: "All day" nodes are not detected as such because of the granularity of the Date field

subscribe

Hi, spending hours during night till the morning. Finally (after a lot of tries elsewhere), I found in file calendar/calendar.module (calendar-6.x-2.x-dev) at line 883 strange arguments:
$node->calendar_all_day = date_is_all_day($node->calendar_end, $node->calendar_end, $granularity, $increment);
After changing the first argument to '$node->calendar_start' "All day" seems to work. Hope it will help someone.

worked like a charm! thank you xaos.cz!

Bug confirmed. #12 worked for me also.

Patch at #10 worked perfectly for my situation were I had multi-day events spread across both the 'All Day' and 'All Times' rows.

The D6 branch is no longer supported so we're closing this issue. If you think this issue still exists in D7 you can open a new one.