Automatic rounding of time values

[jotaen]

If you use the CLI for starting and stopping activities, it puts the exact time values into the file:

2021-05-28
    8:01 - 11:57 Work
    12:22 - 17:49 More work

While that’s most accurate, it doesn’t look very tidy.

Idea: klog round command for cleaning up the data

There could be a command along the lines of klog round, which would go through all entries, and round all times to the nearest 15, 30 or 60 minute value. E.g.like klog round --precision=15m would change the data to:

2021-05-28
    8:00 - 12:00 Work
    12:15 - 17:45 More work

In order for the rounding error to be as small as possible, it would keep track of and account for the carryover while adjusting the values, so that the error never becomes bigger than what the specified precision is.

Optionally, it could add the carryover as additional entry:

2021-05-28
    8:00 - 12:00 Work
    12:15 - 17:45 More work
    -7m

Idea: --precision flag or KLOG_PRECISION= env variable

It could also be that klog start and klog stop take the rounding into account right away. However, then it’s more tricky to implicitly confine the cumulative error, because subsequent invocations don’t know what the previous error was. That’s either okay, or it could be solved via:

• Adding a “compensation” entry (like the -7m above), that’s updated on an ongoing basis whenever you do klog start or klog stop.
• Create a temporary file in the ~/.klog folder.

[vladdeSV]

How would entries with tags be handled? I'm thinking broadly that the carryover would be odd when you round.

In your example, if I add #work tags and follow your example, suddenly more time has been added to the tag #work, but the total is the same.

---

original

2021-05-28
    8:01 - 11:57 #work
    12:22 - 17:49 #work

• total: 9h23m
• tags: #work 9h23m

adjusted

2021-05-28
    8:00 - 12:00 #work
    12:15 - 17:45 #work
    -7m

• total: 9h23m
• tags: #work 9h30m

[jotaen]

Yeah, that’s a good point. Probably better to omit the carryover by default, or otherwise to provide options, like klog round --tagwise or the like.

A related idea in the same vein that I had is something like klog compact, where it would accumulate and combine all duration entries of a record into a single one. E.g.:

2021-05-08
    12:00-13:00
    5m
    10h
    2h30m

2021-05-08
    12:00-13:00
    12h35m

That would pose a similar question: how to deal with tags and summaries. I’m honestly not sure these kinds of “overarching” features are a good idea, since they seem disproportionally complicated.

Maybe the rounding for klog start and klog stop is already sufficient for most use-cases, and the accumulated error might not be that bad in practice. (Especially when rounding to small units, like 5m–15m).

[vladdeSV]

Regarding combining entries, if you go with that, I would strongly recommend you only combine times which do not have summaries to them.

2022-03-03
  30m chill meetings
  7h30m worked really hard

I don't see a way which these could be combined without removing (IMO) crucial information of how the day went.

I do not use the CLI for anything other than parsing times for the previous month, so I don't want to comment on how the CLI should work, regarding klog start and klog stop with rounding.