Separate Time Keeping / timelog?

[alensiljak]

There is certain functionality in Ledger that may not have a direct relationship with accounting, as such. One example is Time Keeping and the timelog entries.

Areas like this are a difference compared to other PTA packages and are not processed by the migration tools.

For the sake of backward-compatibility and the users who might be needing the functionality, the option to read these records should still exist. The existing files should be read and processed.

The question is whether we should separate different apps with specific purposes.
For example, the time keeping could be a separate binary executable that processes only the time keeping entries and outputs certain result (a summary of accounts), which would then be manually entered into Ledger transactions.

This would be in line with the Unix Philosophy, which should ease the development and maintenance of individual tools/areas. Respectively, there might be other areas that would be good candidates for extraction into separate packages, preserving the functionality intact.

Not to mention that there might be different time tracking packages out there that may be better suited for the purpose. The ledger time tracking was too simple for the needs of my projects, for example.

Also, to consider an additional file extension(s) for time tracking files.

Pros: reduce code complexity, separation of concerns

Cons: Change of patterns for the existing users

[colindean]

I think it'd be important to understand how many ledger users interleave TK and regular transactions. I've used TK mode more regularly and consistently— daily 2012–2014 and daily since 2017, — than I have transaction mode for the 10+ years I've been using ledger. I'd be OK with having a separate program and separate parser for the format. IIRC @jwiegley added TK mode because it was pretty easy to massage into the TX data structures, and that might remain the case for the Rust implementation of the data structures but it probably shouldn't be a priority.

[alensiljak]

Thanks! That's some interesting background info. I was thinking more along the lines of separating different issues (and executables). The TK CLI could read the same files and process just the syntax it understands, for example.
One of the main drivers of this idea is (again) #2. The other PTA apps don't have this functionality and ignore the syntax (at best).
I agree that this is not a priority in delivery but would like to throw the idea out there and get exactly this kind of feedback.

How do you think we could ever find out "how many ledger users interleave TK and regular transactions"? There's clearly more features (and I'm focusing mostly on the incompatible ones between the big 3 PTA applications) where it would be interesting to see the usage numbers and patterns.
Thanks again for the feedback!

[colindean]

How do you think we could ever find out "how many ledger users interleave TK and regular transactions"?

TBH, it's gonna be hard beyond asking on the Ledger-CLI Google Group, in the couple of chat rooms linked from https://plaintextaccounting.org, and on /r/plaintextaccounting. Gotta ask where the people are.

[simonmichael]

Keeping more formats in one file makes writing parsers more costly and makes it harder to give good parse error messages. hledger requires timeclock data to be in its own file, but you can still read those files as one big journal. I can't imagine many people routinely keep both kinds of data in one file, it's not efficient for editing or tools.

[alensiljak]

I think that one of the main arguments for such separation is that it makes a relatively minor difference for the end-user but might make a significant improvement in the maintainability of the code. Untangling various different features would allow developers to focus on certain functionality area when working on the code. I think that exactly this aspect might be one of the main reasons of the Ledger's slow progress recently. There is so much functionality mixed in, increasing complexity and making a tall barrier to entry when changes are to be introduced in any of those areas. Having multiple packages (executables?) would likely be easier to work with.

Adding the link to Unix Philosophy to the original question.