Rounding strategy should be different for start and for end time

[QuAzI]

Currently rounding always looks into the future
But start time always should be in past (or from prev task which just closed)

[jotaen]

I think there are three rounding strategies available:

• Flooring
• Ceiling
• Rounding-to-the-nearest

To me, the rounding-to-the-nearest strategy would seem most natural, e.g.:

• 16:59 → 17:00
• 17:01 → 17:00

Especially when rounding with larger rounding values, such as 15m, flooring or ceiling might feel a bit off:

• 16:59 → 16:45 (flooring with 15m rounding value)
• 17:01 → 17:15 (ceiling with 15m rounding value)

I understand that this might be a matter of personal preference, though.

My thinking is that it’s important that the rounding strategy is the same for both start and end time, so that rounding errors even out over time – i.e., sometimes you win, sometimes you lose. Otherwise, if the start time is always floored and the end time is always ceiled, then you’d always “win” a few minutes.

[QuAzI]

I don't think it should look like Excel. As it time reports, the most positive way is to cover empty space by current activity. Also, there is no sense to track already started action like action in future. For example, some tasks can be finished before the next 15 min period starts. So they will look like 17:15-17:15 in case if I start at 17:01?

[jotaen]

If you start your activity at 17:01, then a 15m rounding value would turn the start time into 17:00 in the file. You can only end up with 17:00-17:00 in the file, in case you end your activity before 17:08. I.e.:

• 17:01-17:07 (actual activity) → 17:00-17:00 (logged in file: 0m)
• 17:01-17:08 (actual activity) → 17:00-17:15 (logged in file: 15m)

I think there will always be weird edge-cases with rounding:

• With the current “rounding-to-the-nearest” strategy, a 15m rounding value would turn an activity of 17:08-17:22 into 17:15-17:15.
  • So an activity actually worth 14m would turn into 0m logged in the file. Not great.
• With a “floor-start-time and ceil-end-time” strategy, a 15m rounding value would turn an activity of 17:14-17:16 into 17:00-17:30. It would then also turn a subsequent activity of 17:16-17:17 into 17:15-17:30.
  • So 2 subsequent activities actually worth 3m total would turn into 45m logged in the file, with overlapping time ranges. Not great either.

In the end, I think there is no right answer here. The only advice that I can give is that I think the rounding value should be proportional to the expected duration of an activity. If you expect your activities to be only a few minutes, then you shouldn’t use a 15m rounding, because that will likely produce weird results with any strategy. However, if your activities are usually in the, say, 2h+ range, then a 15m rounding value will probably be fine in practice (as will any other rounding strategy).

[QuAzI]

To avoid time overlapping previous record end time should be checked anyway. If some activity already booked - new timeline should start from prev end time. If no activity before - floor-start should be fine