Feature request: around 'midnight' aggregation method

For time related goals it would be helpful to be able to make time continuous around midnight.

Use case:
A Bedtime goal that goes over midnight, so that I can enter things in simple human terms like:

27 23:02
28 00:05
01 01:15
02 22:54

And have it graph nicely.

Aggregation method pseudocode
for each p, if p < 12:00 then p = p + 24.


Good point, and I love this way of beeminding time! Two concerns:

  1. This is more of a data translation layer before the aggregating. We could implement this as an aggregation method but it’s not as elegant because technically you need “midnight-sum”, “midnight-last”, etc. I.e., your pseudocode adjusts the points for post-midnight but then how do you actually aggregate to pick the official datapoint for the day? I guess this is typically a Do More goal and “midnight” could just mean “midnight-sum” and call it good enough.
  2. Why not just apply that translation manually? It doesn’t take much mental math to enter 1:15am as “25:15”.

But I like experimenting like this and will totally throw it in if you want it.

Does the new clocky aggregation handle timepoints either side of midnight?

1 Like

I agree this is a misuse of the aggregation functionality.

It would be better if beeminder offered a ‘transformation’ method to do this sort of thing to every point entered.
Computers should do the computing tasks, humans should do the human tasks.

For something like bedtime I’m only going to be entering one a day, so if you need to pick an aggregation mode: “midnight-max” probably makes the most sense for a bedtime goal.
If I got to bed at 23:00, realise I’ve still got some eeps to clear, get up and go to bed again at 00:05 I want the value graphed to be 24:05 and not 47:05.

Applying it manually makes the input data look wrong & it’s a simple calculation that computers are good at.

1 Like

No, it just takes differences between successive pairs and sums them. The translation from, eg, “0:30” to 0.5 happens before aggday sees it. It could still apply the translation (x<12 ? x+24 : x) though if that’s what people actually using clocky want.

Mostly I’m liking @insti’s idea of having something like transpoint that all the datapoints are passed through (any ℝ→ℝ function) before aggday touches them. I shall restrain my enthusiasm until we have more use cases though! (:

1 Like

clocky should be able to handle midnight gracefully; the time difference implied by each successive pair must be a positive number.

But I’ve just clocked <groan> that @insti was talking about beeminding bedtime, i.e. single datapoints.


I just discovered what beeminder does to input time data anyway. :fearful:
It turned my nice 23:53 into 23.883333333333333
I would prefer that the input data not be mangled.