Allday option is causing misleading end dates in month view and allday section

9 posts, 1 answers
  1. AndersSpetz
    AndersSpetz avatar
    8 posts
    Member since:
    Apr 2016

    Posted 25 Aug Link to this post

    Hello,

    this post is actually one part a question about the rationale behind the design of the allday option, and one part a question about how to work with this behavior or how to override it.

    To understand what I am talking about, consider following scenario:

    Open the calendar in the regular month view. Already present in the view is an allday event on, let's say, the 19th. Then create a new event on the 19th without the allday option. Both events take up one day slot now. Continue resizing both events to also span the 20th day slot. The allday event will get the end date 20th and the non-allday event will have the end date 21th.

    I know this is because the end time is set to 21th 12:00 AM. My question is why non-allday end dates are exclusive while allday end dates are inclusive? This gets really confusing when working with views where time information is unimportant, like the month view or the allday section of the week view.

    We have use cases where the time information is completely unimportant for the task that involves the scheduler, and in these scenarios the users struggle to understand why it works in one way sometimes and some other times it works in another way. The problem arises because the data that is interacted with actually have time information, only that is not of concern for the user in the interactions in question.

    If this really is the intended behavior, is there a way to override this behavior? I think a solution to our scenarios would be to treat both end dates in an inclusive manner, like this: non-allday event end at 20th 23:59 on resize, allday event just end at 20th.

    Thankful for any kind of help.

    Best regards

  2. Tyler
    Tyler avatar
    24 posts
    Member since:
    Feb 2017

    Posted 25 Aug in reply to AndersSpetz Link to this post

    Any event that is 24 hours or more, will go into the all day event. However, if an event is over 24 hours, it isn't 'marked' all day by the scheduler's all day indicator.

    When you want the all day set to true, then the start and end date of the event must be the same. This gets you start date of 12:00 am on the 20th and end date of 12:00 am on the 20th. When you break this by making the event start and end date not the same, you should not mark it as all day. If it is over 24 hours, the scheduler will correctly place it in the all day space in the scheduler.

    I am not 100% following the scenario you talked about, but I am thinking it is your all day event is stretching two days instead of just one?

     

    If you treat the all day events like I mentioned above, this behavior goes away. Keep all day events to only events that have the same start and end date and time. Anything that does not have the same start and end date and time, do not mark as all day.

  3. Ivan Danchev
    Admin
    Ivan Danchev avatar
    1265 posts

    Posted 28 Aug Link to this post

    Hello Anders,

    As Tyler explained events that span 24h or more are displayed in the "all day" row, just like "all day" events. However an "all day" event has the same date set as start and end date, thus it starts and ends in a single day, whereas the start and end days are different for a 24h+ event. This difference is intended and is by design.

    Regards,
    Ivan Danchev
    Progress Telerik
    Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.
  4. AndersSpetz
    AndersSpetz avatar
    8 posts
    Member since:
    Apr 2016

    Posted 01 Sep Link to this post

    Thank you both for your replies. However they do not solve the problem I (at least tried to) describe.

    I completely agree with you that the events that are 24h+ should not have the allday option set. The problem is that, regardless how it is handled, the end date goes from being inclusive to being exclusive if the allday option is disabled. This is rather confusing for a user that have learned to expect inclusive treatment of end dates. Having this conception of end dates, the month view seems inconsistent when working with the dates of mixed allday and non-allday events, as the same kind of visualization of event "ends" does not result in the same date.

    This behavior does not go away by treating the allday option as you described. Therefore I am asking for a way to treat non-allday events end dates in an inclusive manner. Like this, if I describe it with the correct allday option configuration:

    Allday event: 20th august - 20th august (this is the whole day on the 20th of august)

    Non-allday event: 19th august 00:00 - 20th august 23:59 (this is spanning two whole days, 19th - 20th)

    In this way, the dates are always consistent regardless of what the allday option is set to. In the month view (and allday section) this means that an event that visually end on the 20th, indeed ends on the 20th. Current behavior the non-allday event would end on the 21st in this case.

    Thanks beforehand for your reply.

    Best regards.

  5. Tyler
    Tyler avatar
    24 posts
    Member since:
    Feb 2017

    Posted 01 Sep in reply to AndersSpetz Link to this post

    You may need a dojo example demonstrating this issue to make it clear what exactly is happening vs. what you are expecting/wanting.

    You can manipulate the start and end time in the scheduler's edit event. In the edit event, grab the start and end time inputs and manipulate them how you want when the scheduler view is 'month'. That way, you can avoid being at the mercy of automatic behavior that may seem to be doing something weird and give you control of it.

  6. AndersSpetz
    AndersSpetz avatar
    8 posts
    Member since:
    Apr 2016

    Posted 01 Sep Link to this post

    I cannot seem to login to the dojo tool with my credentials. At the end of this post is a code snippet that demonstrates the issue I have, just paste into a dojo and try it out.

    The problem is that the behavior I described in my previous post results in, is that the exact same visual representation of data, actually represent two different date values. When this occurs, our users get confused. That is the problem I try to solve.

    You can manipulate the start and end time in the scheduler's edit event. In the edit event, grab the start and end time inputs and manipulate them how you want when the scheduler view is 'month'. That way, you can avoid being at the mercy of automatic behavior that may seem to be doing something weird and give you control of it.

    This is what I ended up doing today. Why I sought after a way to override the visual behavior is that now I need to do a temporary date mapping and adjust the dates to guard against this ambiguous visualization of our already existing data. This solution feels a little hackish, so I would appreciate some insights in how the behavior could be altered to always treat end dates in an inclusive manner, both when editing and when visualizing them.

    Thanks again for your time and efforts.

    <!DOCTYPE html>
    <html>
    <head>
        <meta charset="utf-8"/>
        <title>Kendo UI Snippet</title>
     
     
        <script src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
    </head>
    <body>
       
    <div id="scheduler"></div>
    <script>
    $("#scheduler").kendoScheduler({
      date: new Date("2017/6/6"),
      views: [ "month", "week" ], // day and month views
      dataSource: [
        {
          id: 1,
          start: new Date("2017/6/6 00:00 AM"),
          end: new Date("2017/6/6 00:00 AM"),
          title: "Inclusive end date",
          isAllDay: true
        },
        {
          id: 2,
          start: new Date("2017/6/6 00:00 AM"),
          end: new Date("2017/6/7 00:00 AM"),
          title: "Exclusive end date"
        }
      ]
    });
    </script>
    </body>
    </html>
  7. Tyler
    Tyler avatar
    24 posts
    Member since:
    Feb 2017

    Posted 01 Sep in reply to AndersSpetz Link to this post

    Pasting that code into the Dojo showed two events contained to one day, no duplicates or anything out of the ordinary. I am still not fully grasping what is happening. You don't need to log into the Dojo. You should be able to Go Here and modify the dojo until you get your stated behavior. When you go to that link, you will see that both events are contained in the 6th day of the month.
  8. Answer
    Ivan Danchev
    Admin
    Ivan Danchev avatar
    1265 posts

    Posted 05 Sep Link to this post

    Hi,

    With regard to achieving consistent end date to both allDay events and events spanning more than 24h on resize you could subtract 1 minute from the latter's end date. Here's a dojo based on your example. A resizeEnd event handler is added to the Scheduler. Both events start on June 6 and if resized to June 7, both will end on June 7 (the AllDay event at 00.00, the other event at 23:59).

    Regards,
    Ivan Danchev
    Progress Telerik
    Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.
  9. AndersSpetz
    AndersSpetz avatar
    8 posts
    Member since:
    Apr 2016

    Posted 05 Sep Link to this post

    Thanks again for your replies. 

    As I said in above post, modifying the end date on resize was the solution I went for. Now I know that this is also the preferred way to do it. 

    I needed to do a couple of more things though, to get rid of the ambiguity demonstrated by the calendar events in my example. That is, I do a remapping of dates on data read as well, to guard against this behavior. This is for already existing data, that have end times that result in the wrong visualization.

    So the full solution to my problem is: modify end dates on resize/move, as well as temporarily modify dates on datasource read, in case there exist incompatible end dates in already existing data.

    I have been able to proceed now, so I will mark this as solved. 

    Thanks again for your time

Back to Top