Should date-related filters refer to record date or to real date

[jotaen]

This was originally brought up by @ccjmne in #285 (comment).

Currently, all date-related filters (such as --today, --since, --date, etc.) refer to the “formal” date of the record, not to the “real/actual” date. Consider this example:

2000-01-01
  22:00-1:00>

• When you do klog total --date 2000-01-01 then it reports 3h
• When you do klog total --date 2000-01-02 then it reports 0m.

Formally speaking, this is correct, because the --date filter applies to the record date. Logically speaking, this is not correct, because the 3h would actually split across two adjacent calendar days (2h+1h).

The same applies for open ranges:

2000-01-01
  22:00-?

Say on 2000-01-02 you do klog total --today --now, then it would report 0m, even though yesterday’s open range is still ongoing.

Currently, this behaviour is by design, but I see how it may create confusion.

I’m not sure whether this would resolve if the notion of the date-related filters were to change from “formal date” to “real date” – it may not be fully intuitive either way. There are also other corner-cases, which cannot be caught at all – think, if a record contains an entry of 30h (which is allowed), then it’s not determined to which of the adjacent days the “overflowing” time would belong.

There could be other approaches, such as emitting a warning if klog detects that there are adjacent records with shifted times or unclosed open ranges.

Ultimately, I suppose this is a bit of a shortcoming of the notation concept of klog.

[ccjmne]

Klog is less "underlying chronological data"-driven than some others, but its notation is really what sets it apart—together with the spotless specification, excellent manuals and good-looking reports!
It's so well put together that it's the one I want to use, even if I intend to primarily manipulate it through the CLI.

In general, I want my systems to blow up if their data is inconsistent: that's a fail-state.
With Klog, considering the excellent support for ad-hoc modification of the "database", I think we can in principle be a lot more lenient, possibly to the point of accepting and working with nonsense, like 30-hour days, because we can and the "database" is essentially a user interface.

Your user isn't counting on you to make sure days don't exceed 24 hours unless you travelled from Paris to Boston that day: the sanitisation is left to the user, by design, and I think it's unique, simple and brilliant.
What I'm getting at is: in this project, I like the idea of being quite tolerant, while emitting warnings.

--
In my original comment, I alluded to the fact that we could probably get away with making each date spanning a Range using "shifted" Time take ownership of the entire Range, in some contexts.
My point was that there is no ambiguity as to where to look for forward-shifts (the date prior), and where to look for backward-shifts (the next date). Though that supposes we know what day follows the 28th of February, which may actually not have been something Klog has access to yet... huh! Of course it does: it processes --yesterday and --tomorrow just fine.

Another dimension to my idea was to restrict the contexts in which this mechanisms would kick off to queries that are only about a single date at a time, and further by having it waiting behind a specific flag.

--
In any case, there's not much value in having this become a reality, because the user also takes responsibility of which date owns the Entry, and frankly, when you think about it: chances are that actually corresponds pretty well to the way you operate your daily life ;)

I would almost recommend to forget about it, were it not for one case that still seems salient: that of querying for the ranges that haven't closed yet. It's quite striking while, just because the clock struck midnight, my --entry-type OPEN_RANGE --today (i.e.: "the ongoing task") disappears.

However, that is trivially resolved by closing Open Ranges that are too far in the past to even be "closeable" by --now. In my case, where I care about the work in progress, I can simply replace --entry-type OPEN_RANGE --today by --entry-type OPEN-RANGE --since $(date -I -dyesterday), or even --entry-type OPEN-RANGE. If I have in my records of daily tasks (Klog's anchor unit is indeed the day) a Range that's opened since last year, that's on me, and I can probably fix it, or choose to forget about it by passing --since <yesterday>.

--
From my perspective, that's pretty much a case closed, pending comments from anybody else having other ideas or needs. After reflection, I'm happy with the current tooling!
That is, short of a way to tacitly ask for "amended" records, like a 09:00 - ? immediately followed by a -1h, when I ask for records of a specific type... But that proposal is coming ;)