DayPilot Forums

I'm not sure I agree with the change you've made to all-day events in v4.7.1399

I did have my all day events as date only and they worked fine, by definition an all-day event does not need a time element.

However in the new version I now find that all my 1 day events (24/04/08 00:00:00 to 24/04/08 00:00:00) do not display at all, and 2 day events (24/04/08 00:00:00 to 25/04/08 00:00:00) only display the first day.

How come now in a 2 day event 24/04/08 00:00:00 is treat as 24/04/08 but 25/04/08 00:00:00 is treat as the day before 24/04/08 23:59:59 ?

I will have to update all 00:00:00 ending times in my database to be 23:59:59, and change my code so that new all-day events have 23:59:59 appended to them

I'm also not sure why you would want to do this :-
' Forum 387 (bug): All-Day events ending at 24:00 were visible on the following day'
There is no such time as 24:00 and I would think that most datetime validations would not let you enter 24:00:00.

To me the real bug was that 00:00:00 single all-day events did not display in the month view and to get round that (forum 387) was adding the 23:59:59 time, which uncovered an additional bug/problem because it now displayed the time in the week view. Therefore the only functionality that needed fixing was the display in month view and the option to hide the time in week view.

sorry for the rant, but it looks like unneccessary work to me.

Still a very good control though.
Thanks

Thanks for your post. I didn't realize this change would have such an impact on users who relied on the existing behavior. My motivation was to unify the behavior of all-day events in DayPilotCalendar and DayPilotMonth. It seems that changing the existing logic causes more troubles than the inconsistency...

The ending time for all-day events can be understood in two ways:

• the exact time point (that's how it's working now in build 1399, in both DPC and DPM)
• the date part of DateTime (logic used in DPC in previous versions)

The optimal solution seems to be adding a property that will specify the mode. I prefer that you can bend DayPilot around your existing data structure and logic rather than having to do the opposite.

The request for hiding the times in all-day events in week view is of course valid and I will add this option as well.

I expect both these changes will be released in a special service pack during the weekend.

And sure, no parser will accept 24:00 time ;-). I used it to illustrate the time point.

Thanks Dan, much appreciated.
Keep up the good work.

Hello,

I'm using version 4.7.1399 as well. I also noticed the new all day behaviour, but the way it behaves now is the right way in my opinion. I had to substract a day of the end datein the previous versions of daypilot. This would give the result of 24/04/0800:00:00 - 24/04/08 00:00:00, which has in fact a timespan of 0 seconds.In my database I have 24/04/08 00:00:00 - 25/04/08 00:00:00 which has a timespan of 24 hours (1 day). In the current version (4.7.1399) I don't have to substract1 day of the end dateanymore and it's displayed in the right way in both the day and month views. So I don't consider this as a bug at all.

In my oppinion it is a waste of time to add a mode for this andwhich could be used for adding doubleclickeventsfor the all day events and the events in the monthview better.

Keep up the good work Dan.

I guess the real issue with this is that allday events dont need a time, just a date as they are by definition All-Day.
So a 1 day all-day event on 23 Apr 08 starts 23/04/08 and ends 23/04/08.

This is how Outlook works if you need to import outlook events into your daypilot.

Its all in the interpretation I suppose.

Thanks for all the inputs.

I see both approaches as valid.

1. If you store all-day events as Date only it makes sense to have both the start and end on the same day.
2. If you use DateTime for all events (including all-day events) you will probably choose to keep the 24 hours duration and store the end as 00:00 next day.

I would say I prefer #2 at the end but the fact that I originally used #1 for DayPilotCalendar proves that it wasn't so clear.

As I said, I'm not going to dictate you how to store all-day events so I will be adding the special property for switching the behavior (it's a 30-minute change after all). The default value will be to use #2 (e.g. full DateTime information).