- π¦πΊAustralia mingsong π¦πΊ
This module is under 'Bug fixing only' status.
So this new feature won't be delivered.
Sorry.
- Status changed to Active
over 1 year ago 4:08pm 3 August 2023 - π¨π¦Canada chrisck Vancouver, BC π¨π¦
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.
- π¨π¦Canada chrisck Vancouver, BC π¨π¦
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:
- Create Event content type with date range field type, with field settings Date Only.
- 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.)
- Create Event with a date only date range.
- On the FullCalendar view, drag and drop the event. Refresh the page. The event is saved as one day longer than intended.
- π¦πΊAustralia mingsong π¦πΊ
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. - π¨π¦Canada chrisck Vancouver, BC π¨π¦
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 is not 00:00:00 in local time. It is 00:00:00 in UTC time. I'm uploading a patch that takes this into account, which I've tested to be working in my setup.
- Status changed to Needs review
over 1 year ago 10:41pm 3 August 2023 - π¦πΊAustralia mingsong π¦πΊ
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.
- Status changed to RTBC
6 months ago 11:08pm 3 June 2024 - πΊπΈUnited States erutan
The patch in comment #7 has been working great for months across a few different calendars built.
- Merge request !68Issue #3213979 by chrisck, mandclu, Mingsong, Jeff-DavRF, erutan: Processing... β (Merged) created by mingsong
- 7651f406 committed on 5.x
Issue #3213979 by chrisck, mandclu, Mingsong, Jeff-DavRF, erutan:...
- 7651f406 committed on 5.x
- Status changed to Fixed
6 months ago 11:55pm 3 June 2024 Automatically closed - issue fixed for 2 weeks with no activity.