Add functionality for all-day events

I took a shot at this. It's a little rough, but it checks the start/end times for 00:00 and 23:59 to make it all day.

Great work. Thanks guys so much.

I will test it when I have a chance.

Just coming back to this - the patch still works on the new 2.0 stable release. It's a great help to me so that I can use all-day functionality in the calendar within one Date Range field in my event content type. So thank you!

I was also facing this issue and came across this thread. In my case, I've been using All Day (https://www.drupal.org/project/date_all_day) feature, so an author can choose either All day checkbox or enter both dates manually. IMO, having both the options in the code would help to manage the "All Day" feature efficiently, hence uploading a revised patch here.

I've tested patch in #7 and it works great, however I'm using both Date_All_Day AND Optional_End_Date module, which is not supported by patch in #7, so this patch continues the good work on previous patches and adds this case as well.

The current patch works in the following cases:

• Start date's time is "12:00:00 AM" a.k.a 0000 in code.
• AND one of the three following conditions:
  • End date is null or empty (which is achievable using Optional_End_Date or core patch from #2794481: Allow end date to be optional).
  • End date's time is "12:00:00 AM" a.k.a 0000 in code.
  • End date's time is "11:59:59 PM" a.k.a 2359 in code (which is achievable using Date_All_Day module).

Thanks for the patch @jwilson3. I created one for the 5.x branch.

Using patch #9 with smart_date 3.0 results provides an error as follows:

Exception: DateTime::__construct(): Failed to parse time string (1621350000) at position 7 (0): Unexpected character in DateTime->__construct() (line 25 of modules/contrib/fullcalendar_view/src/TimezoneService.php).
Drupal\fullcalendar_view\TimezoneService->utcToLocal('1621350000', 'America/New_York', 'Hi') (Line: 292)
Drupal\fullcalendar_view\FullcalendarViewPreprocess->process(Array) (Line: 32)
template_preprocess_views_view_fullcalendar(Array, 'views_view_fullcalendar', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('views_view_fullcalendar', Array) (Line: 431)

@matt_paz it looks like the smart_date module is using Unix timestamp e.g. 1621350000. I am not sure but I think that DateTime is expecting specifically for the calculation of all-day events as it is expecting an ISO timestamp. I think you need the patch from 3061341 and modify the patch for all-day events

@dmundra - Ya, it looks like smart_date works without any additional patches right now after all. I didn't realize it before looking into this patch. At this stage, I just thought you might want to know that it doesn't work with the patch above. Thanks for circling back either way!

Sounds good @matt_paz.

I think we should be cautious about adding code that has been found to create errors in a popular existing combination with FCV, as identified by @matt_paz. Let me take a stab at adding a check for a timestamp to see if that fixes it.

@dmundra Smart Date does indeed use timestamps, and provides its own FullcalendarViewProcessor plugin to pass in the data in a format that FCV can use. Provided nothing will choke on a timestamp before it gets a chance, of course. ;)

Here's a modified version of your code, wrapping the changes in a check to make sure the start isn't numeric.

Thanks, @mandclu. That solution works great.

I've rerolled the patch from #15 for the 5.x branch.

Needed to fix double utc conversion and the daterange type to get it to work for me.

I'm upgrading to fullcalendar_view 5 and #17 works as expected. The calendar is broken with #18. I'm using date_all_day and optional_end_date.

I close it as 8.x branch is not supported anymore.

Which means the new feature quested won't be consider anymore.

Re-opened because the patch in #17 was re-rolled against the 5.x branch and the feature request is still valid (5.x doesn't support all-day functionality for a single day).

Is this feature request meant to address the undesired display of a time on All Day events? If the event is All Day, I don't want the time (12:00AM) to appear on the event in the calendar.

While the original issue summary does not mention using smart_date for all day functionality, smart_date is mentioned quite a few times in the comments. I'm reporting that smart_date 4.0.2 is working out of the box with fullcalendar_view 5.1.12 with all day functionality, without requiring any patches.

Perhaps what some are missing is that the field type has to be "Smart date range" and not, the core "Date range" with Smart date widget.

Download and enable the Smart Date Calendar Kit on a new Drupal install and look at how it's configured.

This patch causes warnings if the end date is not set.

Here is a new patch. Adds some checks for empty values and addressed some phpcs issues.

I updated the patch that @geekygnr left in comment #25 to be compatible with the latest version 5.1.13

@LeonelEnriquez98 The patched worked for the most part but its posting two days. So I post an event for 1 day 11/20 but when viewing it's showing all day for 11/19 and all day 11/20 for the same event. I just added the start date only and also did the same day for Start and End date fields and still the same issue.

@ferminaguilar I could reproduce that error. It was related to the timezone variable. So here I leave the new patch.

@ferminaguilar @LeonelEnriquez98 I still had the same issue with all-day events starting on the day before they should after applying patch #28. I believe the issue is because when finding the start date, it applies the difference from UTC to a date which has already had the difference applied to it. So it applies the timezone difference twice. Here's a new patch.

@jennine Your patch seems to be working fine. Thanks!

Patch #30 fixed the starting a day early for me... but now they are running a day over. My events are pulled from Google. It seems this patch adds an extra day to my events.

Attaching the patch that works for me, but I'm not sure if this just solves my use case.

Changing:
$end = $timezone_service->utcToLocal(empty($end_date) ? $start_date_value : $end_date, $timezone, 'Y-m-d', '1 day');
To:
$end = $timezone_service->utcToLocal(empty($end_date) ? $start_date_value : $end_date, $timezone, 'Y-m-d');

1. +++ b/src/FullcalendarViewPreprocess.php
   @@ -160,8 +160,8 @@ class FullcalendarViewPreprocess {
   -    $timezone = !empty($start_field_option['settings']['timezone']) ?
   -    $start_field_option['settings']['timezone'] : date_default_timezone_get();
   +    $timezone = !empty($start_field_option['settings']['timezone_override']) ?
   +    $start_field_option['settings']['timezone_override'] : date_default_timezone_get();
        // Set the first day setting.
   

   This reverts changes from #3215767: Entries always rendered with the field selected timezone. But that removes support for datetime and daterange formatters.
   timezone is a setting of timestamp formatter.
   This should be fixed in a separat issue to support both formatters.

2. +++ b/src/FullcalendarViewPreprocess.php
   @@ -332,7 +332,7 @@ class FullcalendarViewPreprocess {
   -              elseif (strpos($end_field_option['type'], 'daterange') !== FALSE) {
   +              elseif (strpos($end_field_option['type'], 'daterange_default') !== FALSE) {
   

   This change removes support for daterange_plain and daterange_custom formatters. It should be reverted.

Needs work for 2.

Rebased on 5.x and cleaned up a section with different checks on $options.