[ANGULAR] EventEdit startDateField increment results in 3 days shift

[nickolay]

@rafal Hi, what happens here is that "incrementing" the date uses the event's calendar (intersection of event's and resource's calendars to be precise) and it skips the amount of working time. The hoursPerDay config for project is not set and default value 24 hours is used. Because of that, event moves further in the future than expected.

Probably in this case hoursPerDay=8 setting is assuming.

However the 2nd cause comes into play - the "start date" and "start time" fields are completely separated. So "incrementing" the start date (moving event 8 working hours to the right) may keep it inside the same day (if it starts early, like at 8 AM). Then the date remains the same, time part of it is ignored so increment does not happen at all.

We probably will be combining the "start date" and "start time" fields to use the same data source, so that incrementing a date for event starting at 8:00, with calendar 8:00-17:00 will keep the event in the same date, but instead will change time to 16:00 (assuming hoursPerDay=8).

[rafal]

What about incrementing date by single day. If the resulting time is not available then the time should be moved to the closest available time? It seems more reasonable to me.

When are you planning to fix it?

[marcio]

Hey rafal,

If you're talking about the ticket on this thread, it's already solved and it'll be available on 5.5.2 and 5.6.0-alpha-2.

[rafal]

I have updated scheduler to 5.5.2 version. Nothing changed. The problem still exists. Should I do something special?
The bug also exists in this example:
https://www.bryntum.com/products/schedulerpro/examples/resource-non-working-time/

[nickolay]

This is a breaking change, so it is in the 5.6.0 branch (already available in the 5.6.0-alpha release)

[rafal]

So in order to use production version I have to wait for 5.6.0 version?

[nickolay]

That would be the safest, our alphas passes through the same automated quality control though, so you can try it too already.

[rafal]

Why the startDateField uses hoursPerDay factor? From user perspective it is weird. User just wants to increment/decrement the date by single day. Now it jumps uncertain amount of time forward or backward.

[nickolay]

Start/end date fields use "calendar" time and not just increment/decrement of the dates. This is because of the following use case. Imagine a 24/5 project calendar and a task starting on Monday. We then decrement the start date of that task. To which date it should be set? Setting it on Sunday does not make sense, because of the 24/5 calendar. Setting it on Saturday does not make sense either. The only sensible choice is to set it on Friday, which is equivalent of "shifting start date 1 working day backward".

This is why start/end date fields uses "shift in working time" semantic, instead of the "raw" increment/decrement.