CSV output mechanism

[bevel-zgates]

I actually wrote up a small utility for generating csv files from the klog json output for my own use. If you have any interest @jotaen I can git you a quick PR for upstreaming it.

[jotaen]

I’m actually a bit reluctant to add more output converters, mainly because I worry that it could become a bit of a rabbit hole to create and maintain them all – think: CSV, TSV, XML, etc. My thinking so far was that JSON is quite flexible and universal, so that it allows people to create their own custom converters on top of it.

That being said, if it’s not too much work for you to publish your CSV utility somewhere, then you could share it here for other people to find it. If it turns out that there is high demand for CSV, then I’m open to consider integrating CSV conversion into klog directly.

[jotaen]

Thanks for creating the demo branch! I’m still on the fence about CSV support, because I’m not sure whether there would be a universal output structure. klog data structures are “deep”/nested, whereas CSV is flat. So it’s tricky to decide whether there is e.g. one CSV line per record, per entry, or even per tag. (Note that the record summary also may contain relevant info and tags, which then apply to all entries of that record.) JSON, on the other hand, maps pretty nicely and transparently.

I need to think about this some more. I also want to be honest, though, that I’m currently not super convinced. This isn’t because of CSV itself, but more because of the feature design and maintenance issues. I’m happy to keep your branch and this discussion for future reference.

[bevel-zgates]

I'm happy to keep it in my fork.

I'm a little hazy on the difference in my mental model for differences between an Entry and a Record, but for my use case I was aiming for 1 line/entry/tag. So a line tagged to three different things would yield multiple rows.

This is helpful for my bookkeeper in being able to take a block of hours and contribute it to a project/customer with out requiring any additional work beyond the original klog track.

Want me to close the branch for now or just leave it stale for the time being?

[jotaen]

We can close the PR for now, but I think Github will preserve the branch so that we’d be able to come back to it in the future.

Regarding terminology: a record is the overall “block” of data for one day, including the date, the initial record summary and all entries. The entries are the indented times, along with their respective line summaries.

2024-07-23
This entire #thing is a record
   2h This is one #entry
   8:00-9:00 This is #another entry

Note that if there is a tag in the record summary, then it applies to all entries. So in the above example:

• #entry → 2h
• #another → 1h
• #thing → 3h (=2h+1h)

In other words: the tags from the record summary behave as if they were applied to (repeated on) each entry. So the entries basically “inherit” the tags from the record.

[spi43984]

jq is your friend here.

Check out for instance

./klog json --tag=whatever | jq '.records[] | [.date, .entries[].total_mins, .entries[].summary]'
./klog json --tag=whatever | jq '.records[] | [.date, .entries[].total_mins, .entries[].summary] | @csv'

jq howto

[bevel-zgates]

Oh I didn't know about @csv that's nifty. In my case I wanted to be able to do things like extract the tags out of the summaries, and produce n outputs for different clients/projects, but probably I should have just played with jq more =)