Use case:
-
Back-to-back slots (09:00–10:00 and 10:00–11:00) shouldn’t count as a conflict.
-
Current
overlaps withis inclusive, so it flags these as overlapping. -
Need a native exclusive option so adjacency returns false without Advanced filters.
Use case:
Back-to-back slots (09:00–10:00 and 10:00–11:00) shouldn’t count as a conflict.
Current overlaps with is inclusive, so it flags these as overlapping.
Need a native exclusive option so adjacency returns false without Advanced filters.
Can you get around it by setting the slots to 09:00-09:59, etc) instead? You could probably do that and still hide it from the UI if your prefer.
Time is stored as absolute Unix time (I write about that here), so the way overlaps with works, they are technically overlapping.
Just realized you posted this in the idea section, so maybe my solution came across as obvious.
As an idea, I support it—would be useful indeed!
Hi Petter,
Yes its feasible to create ways around it, but it seems like we shouldn’t have to because arguably in 50% of use cases you could consider time slots to not be strictly overlapping if one stopped at the same time another started. Would be useful to allow both interpretations.
Agreed! I’ve worked with that challenge before and the workarounds can add some unnecessary complexity: mostly, timespans are selected in 30/60 minute slots, not 29 and 59.
Tagging @fede.bubble here to see what he thinks.
I also have faced this many times in the past. Maybe this is another case of a new operator option (like these ones) that should be added to make our lives easier and prevent workarounds.