Event object utils for getting/setting an event's inclusive end date

I know that the end date of allDay events is exclusive (http://fullcalendar.io/docs/event_data/Event_Object/). I know that this is technically the same for ical.

We have a backend/CMS where users enter the events and their dates. For example, a 3 days event from 16th June to 18th June. There is no way that I can teach my users that this event should be entered as 16th June to 19th June instead of what it actually is. Maybe this is also a cultural thing (germany in my case).

An option like endIsInclusive (default: false) would be very much appreciated.

I found various requests for this issue: https://github.com/fullcalendar/fullcalendar/issues/3098, https://github.com/fullcalendar/fullcalendar/issues/270, https://github.com/fullcalendar/fullcalendar/issues/2653, https://github.com/fullcalendar/fullcalendar/issues/2517, https://github.com/fullcalendar/fullcalendar/issues/2909, https://github.com/fullcalendar/fullcalendar/issues/1028, https://github.com/fullcalendar/fullcalendar/issues/2640, https://github.com/fullcalendar/fullcalendar/issues/2268, https://github.com/fullcalendar/fullcalendar/issues/2344, http://stackoverflow.com/questions/25941499/fullcalendar-multi-day-event-spans-1-day-too-short#comment40626092_25942710

What makes this worse, there seems to be no easy workaround for this issue, see https://github.com/fullcalendar/fullcalendar/issues/2344#issuecomment-132572231

[jhwinters]

Rather late I know, but I have a possibly helpful suggestion for atilleul.

You quite rightly say that your users don’t want to have to enter 2016-06-01 to 2016-06-02 for a one day event - and they shouldn’t have to.

The problem arises however because of the inconsistent way in which people refer to the duration of events. When we say “From Wed 1st to Fri 3rd” we implicitly mean “From the start of Wed 1st to the end of Fri 3rd”. There is no reason (nor indeed feasibility) to get people to change, but it’s important to identify the inconsistency in order to handle it in the cleanest way.

The point to apply the correction is at the point of data entry. Thus when a user enters:

Start: 2016-06-01 End: 2016-06-03

meaning to create a 3 day event, your system should recognise what they mean and interpret appropriately. The user means “from the start of Wed 1st to the end of Fri 3rd” and so that’s what the system should store. The start of Wed 1st is “2016-06-01 00:00:00” and the end of Fri 3rd is “2016-06-04 00:00:00”

Your data store (and not just FC) needs the information stored like this because otherwise it can’t do correct calculations on duration or event overlap. If you store the end date as 2016-06-03 in your database, you won’t be able to do meaningful queries referencing that date field. Comparing, say, “2016-06-03 09:00” to “2016-06-03” will indicate that the former is after the latter (which it is). However “2016-06-03 09:00” is not after the end of your event.

If you want to work out the duration of your event, you do 2016-06-03 - 2016-06-01 and whoops - wrong answer! You need to adjust the calculation and do (2016-06-03 + 1 day) - 2016-06-01.

If you have another event running from the 2nd to the 5th and you store that as 2016-06-02 to 2016-06-05 then how much do they overlap by? 2016-06-03 - 2016-06-02 gives an answer of 1 day. Whoops - wrong answer again! Again you need to apply a frig factor, giving (2016-06-03 + 1 day) - 2016-06-02.

2016-06-03 simply isn’t the end date of your event. Fix your data storage and all becomes simple.

Of course, when you come to show the timings in a textual form again (e.g. because the user is editing the event) you need to adjust the end time back to the user’s expectations again.

Any other approach than this will inevitably lead to frig layered on frig layered on frig. Fix the problem at the point of source (the fact that people use a slightly inconsistent notation) and then everything else flows smoothly. You can’t fix the people (nor should you want to) so fix the data at the point of entry.

Take a close look at a 3 day event displayed in FullCalendar and ask yourself where the coloured bar ends.

[arshaw]

Ah ok, sorry for the missing the point. I’ll change the title.

I’m hesitant to have a setting that alters such core behavior for two reasons:

1. will make the internal code more complicated. everywhere an end date is manipulated they’ll have to be conditional behavior.
2. when people are using this behavior, and are viewing examples on the internet, the example might not match because and they’ll get confused.

Eventually I want to move towards Event Objects being prototype-based objects with real methods. When that happens, I can introduce two new convenience methods: setNaturalEnd and getNaturalEnd, which will do the +/- math for you. An event object could also accept a naturalEnd date input property.

What do you think?