Simon Michael

Yup, I meant with "Clockins/clockouts split across files". I think you aren't clocking in in one file and clocking out in another. As long as you keep clockins/outs nicely paired...

By "merge them first" there I meant the manual merge process, like `sort a.timeclock b.timeclock | sponge a.timeclock`.

Yes, making this more flexible (eg, ignoring "orphan" clockouts) would fix the "2. Clockins/clockouts split across files" problem.

It needs some design, indeed. A bit of research: - https://hledger.org/dev/hledger.html#timeclock and [doc source](https://github.com/simonmichael/hledger/blob/095f65d9b40ca6ec0e259f2e982e64d6441dd68c/hledger/hledger.m4.md?plain=1#L4110C1-L4110C12), [tests](https://github.com/simonmichael/hledger/blob/master/hledger/test/timeclock.test), [implementation](https://github.com/simonmichael/hledger/blob/master/hledger-lib/Hledger/Read/TimeclockReader.hs) - hledger's timeclock format. hledger currently requires a strict i, o, i, o alternation,...

So following the [imagined] Ledger design, I'd expect the second output - the first, generic, o closes the most recent i (github), and the second o closes the next most...

I did some testing and updated the notes above. Ledger, like hledger, does not allow an orphaned o in a file of its own. But if you combine the above...

So a question to think about, when considering multiple input files, possibly with multiple formats: What time-related checks are performed on (a) individual timeclock files, (b) the combination of all...

Though that b. (allowing orphan o's in individual files, but disallowing it in the combined timeclock data) feels both tricky to implement, and likely to bring the kind of data-order-dependent...

Good example! It gives a strange balance report since 1.22, as you say. I welcome any help with this.

Switching to seconds as the internal commodity does sound sensible, but I'm not exactly sure how to make it fit. Ideally the external behaviour would remain the same at least...