Output of today subcommand

[ulken]

Just curious, how come klog today outputs Other and All?

Personally, I find it unexpected (given the name today) and undesired. All I'm after is the forecasted end time.

[ulken]

Isn't that information already available via klog total --diff --now?

[jotaen]

klog today is a special-purpose, convenience command that’s meant as a check-in or overview of your tracking data from today’s perspective. Think: “were am I right now time-wise, and how does that relate to the rest of the data?”.

Without the “other” and “total” row, klog today wouldn’t be much different from klog total --today / klog total --today --diff --now, except for the end-time forecast. I didn’t want to add the end-time forecast to klog total, though, because otherwise the behaviour of klog total would become too complex.

I personally find the “other”/“total” info in klog today helpful, because that context makes it easier for me to sanity-check my data at one glance, even when I’m primarily interested in today’s data. It might not be needed or desired for all use-cases, but it also shouldn’t harm too much, except that the output could potentially be perceived as slightly less clean.

That being said, I think the name of klog today command is certainly not perfect, but it was the best I could think of. I’d still prefer it over alternatives like klog check-in or klog overview, because it communicates that the focus is on the current date (even if that’s not meant in an exclusive way).

[jotaen]

One additional note on the forecasted end-time: the end-time differs depending on which fraction of the data you consider. Think:

2020-01-01 (8h!)
    6h

2020-01-02 (8h!)
    8:00-?

Assuming that right now it was 2020-01-02 at 15:00 o’clock, then your forecasted end-time of just today would be 16:00, but overall it’s 18:00, since you have an accumulated “time debt” of 2h from the day before. That’s an important distinction, which I think is more obvious by splitting the data between “today” and “total”.

[ulken]

Makes sense. Thanks for the explanation. Yeah, I realize usages differ.

I've added some shell aliases/functions to fit my workflow.

The only part I can't really workaround in a sensical way is negative time ranges. Requires manual editing.

[jotaen]

The only part I can't really workaround in a sensical way is negative time ranges. Requires manual editing.

I hear that, and #109 is still on the table. Realistically speaking, however, I have to say that adding negative time ranges is a pretty comprehensive undertaking – deciding on the syntax and semantics is the easiest part, but extending the spec, writing and refactoring the code, and documenting it will be substantial effort. It might eventually happen, but it would certainly take a while.

[ulken]

I get that. Like I said, let me know if you need a hand on something.