What in a rundown is the day after?

[cpvalente]

We want to improve Ontime's ability to infer scheduling from the rundown.
Specifically, how do we know that an event is the day after?

The problem

Consider the following

Example 1
Event 1 - 09:00 - 10:00
Event 2 - 08:00 - 09:30

Example 2
Event 1 - 09:00 - 10:00
Event 2 - 09:55 - 10:25

We typically say that the Event 2 in Example 1 is the day after
While we can infer that in Example 2, there is an overlap of 5 minutes

It seems that we instinctively do it because the distance in Example 1 is considerable while it is small in Example 2.
However, I can't find a hard rule for what should be classified as an overlap and what is the day after.

For a more complicated case:

Example 3
Event 1 - 09:00 - 10:00
Event 2 - 09:30 - 10:30

Is this day after or has a 30min overlap?

Going forwards

Ontime does not have a concept of days, all times are milliseconds from midnight.
Currently, we consider that your rundown is in order. With this, we infer:

Example 4
Event 1 - 09:00 - 10:00
Event 2 - 09:30 - 10:30 <--- Event 2 starts after event 1, 30min overlay

Example 5
Event 1 - 09:00 - 10:00
Event 2 - 08:30 - 10:30 <--- Event 2 starts before event 1, day after

However, this is opinionated, and we could be giving incorrect feedback to the user.

I appreciate any thoughts on how to improve the feature in Ontime.

• Can we find a hard rule for the classification?
• Should the user be able to clarify this classification manually?
• Something else?

[lukestein]

I am new, just checking the tool out a bit, and probably not really the typical user, so all can be taken with a grain of salt. But.

It seems there's a bit of a conflict if ontime is going to

1. Avoid having a notion of days,
2. Maintain tracking all events as ms since midnight,
3. Straightforwardly support events on different calendar days, and
4. "Allow" rundowns with start times that are out of order.

One (bad) solution would be to assume that all times are expressed relative to the same midnight. If a user wants an event to start the next day, they would need to enter it as e.g., 25:00?

There's a separate but related question how to think about "overlaps." For me if Start2 is before Start1, that's not an "overlap," that's a "Events out of order."

That is, in your examples above:

1. Example 1 → Events out of order (no overlap calculated)
2. Example 2 → 5 minute overlap
3. Example 3 → 30 minute overlap
4. Example 4 → 30 minute overlap
5. Example 5 → Events out of order (no overlap calculated)

But of course, sometimes what I called "Events out of order" is clearly actually a case of event starting the next day

Example 6
Event 1 - 22:00 - 22:30
Event 2 - 00:15 - 00:45

[cpvalente]

Thank you @lukestein, we are trying to fine tune the apps behaviour here and the help is appreciated

It seems there's a bit of a conflict if ontime is going to

Avoid having a notion of days,
Maintain tracking all events as ms since midnight,
Straightforwardly support events on different calendar days, and
"Allow" rundowns with start times that are out of order.

I completely agree and we have done several changes to become stricter here.

We feel Ontime is a tool that should work well for planning a sequential event. ie: a single project
However, in our industry it is not uncommon projects run over midnight. Even if we dont want to fully support the idea of multiple-days, we need to allow users to have a contiguous rundown that crosses midnight

Previously we maintained pretty complex logic to try and guess whether an event was out of order, or the day after. But as v3 we decided to simplify to say, "if this event starts before the previous, it must be the day before". We show the tag to support this to the user and let them make the decision

The midnight cross doesnt actually mean much for the application if the user is not in roll mode

I believe this is a good compromise and the least surprising path for the feature. What do you think?