Processing all day events via drag and drop

This module is under 'Bug fixing only' status.

So this new feature won't be delivered.

Sorry.

Hi @Mingsong there is a bug with the event dragging as previously reported by @mandclu. The bug is in the eventDrop callback function in fullcalendar_view/js/fullcalendar_view.js on line 221:

 // Event drop call back function.
  function eventDrop(info) {
    const end = info.event.end;
    const start = info.event.start;
    let strEnd = '';
    let strStart = '';
    let viewIndex = parseInt(this.el.getAttribute("calendar-view-index"));
    let viewSettings = drupalSettings.fullCalendarView[viewIndex];
    const formatSettings = {
        month: '2-digit',
        year: 'numeric',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: '2-digit',
        timeZone: 'UTC',
        locale: 'sv-SE'
      };
    // define the end date string in 'YYYY-MM-DD' format.
    if (end) {
      // The end date of an all-day event is exclusive.
      // For example, the end of 2018-09-03
      // will appear to 2018-09-02 in the calendar.
      // So we need one day subtract
      // to ensure the day stored in Drupal
      // is the same as when it appears in
      // the calendar.
      if (end.getHours() == 0 && end.getMinutes() == 0 && end.getSeconds() == 0) {
        end.setDate(end.getDate() - 1);
      }
      // String of the end date.
      strEnd = FullCalendar.formatDate(end, formatSettings);
    }

I've read through your comments and I understand why we need to subtract one day from the end date, however the following if() statement isn't triggering. So I printed the end date value to an alert and found the issue:

    // define the end date string in 'YYYY-MM-DD' format.
    if (end) {
      // The end date of an all-day event is exclusive.
      // For example, the end of 2018-09-03
      // will appear to 2018-09-02 in the calendar.
      // So we need one day subtract
      // to ensure the day stored in Drupal
      // is the same as when it appears in
      // the calendar.
      alert(end);
      if (end.getHours() == 0 && end.getMinutes() == 0 && end.getSeconds() == 0) {
        end.setDate(end.getDate() - 1);
      }

The end date alert is showing as:

17:00:00 GMT-0700 (Pacific Daylight Time)

This is why the if() statement isn't getting triggered, because the hours don't match up. So I updated the if() statement and the end date is now getting subtracted by one day as originally intended.

if (end.getHours() == 17 && end.getMinutes() == 0 && end.getSeconds() == 0) {

I'm not sure if this is the ideal solution, but definitely highlights some work needed here. I'm not sure where the 17:00:00 GMT is coming from, is this just a default value if the date value is null?

Lastly, the same issue is present in the eventResize() callback on line 84.

I've just tested this issue with FCV and Drupal core's date range field type and the issue still exists.

Steps to reproduce issue:

1. Create Event content type with date range field type, with field settings Date Only.
2. Create FullCalendar view with date range field. In the Format: Full Calendar Display, settings select Start Date field and End Date field to be the same date range field (be sure when adding the field, select the first option and not the one that says [fieldname] - Duration, [fieldname] - End etc.)
3. Create Event with a date only date range.
4. On the FullCalendar view, drag and drop the event. Refresh the page. The event is saved as one day longer than intended.

The 17:00 should be coming from the jet lag, that saying it depends on what Timezone the server is in and the client browser is set.
We can’t simply use the specific time difference as the indicator, in your case is “17:00:00”. As a contribute module, it should work for all Timezone.

There seems to be a mix up of the date functions used getHours(), getMinutes(), getSeconds() with local and UTC time.

The if() statement is not getting triggered because end constant for all day events is 00:00:00 in UTC time, not local time. But the functions mentioned above is looking at local time. I'm uploading a patch that takes this into account, which I've tested to be working in my setup.

Sounds reasonable move.
Let's see what feedback on the patch from others.

This patch fixed the bug for me. I think it would be a very good idea to approve this patch because without it the wrong date is set when you drag and drop or move the end date on the calendar. This means that without the patch every time the event is dragged to a new start date it adds a day to the end of the event.

The patch in comment #7 has been working great for months across a few different calendars built.

Thanks everyone.