--currency obedience for JSON reports

[MrPixelized]

I'm generating PDF reports based on hledger data, and the JSON report format is the most convenient for that (even though the way it serializes the data is a bit unpleasant to work with).

I'm finding that there's no way to adjust the precision on the floating point values, though as a user I was expecting there to be at least some way to obtain the values as they would be rendered in a regular hledger report, including overriding the formatting using -c.

Of course, there is also astyle. HOWEVER. Its values do not change when adjusting the precision using --commodity-style. It's also a bit inconvenient to use.

What would be a good way to help here?

One way that's backward-compatible is to add a hledgerRendered field or such to the aquantity field.

[simonmichael]

Thanks for the feedback on JSON output, we haven't many (known) users of that yet.

Yes, I think as you guessed our numbers in JSON output are intentionally a fixed machine-readable format, not affected by -c/--commodity-style which is mainly for human-/hledger-readable output.

Some related mentions in docs:

• https://hledger.org/hledger.html#json-output
• https://hledger.org/hledger.html#amount-parseability (could link to json's particular behaviour here)

What kind of numbers would be more useful to you in the JSON ? Can you simply round them to lower precision ?

[MrPixelized]

In the end I decided to go from the CSV output to my own JSON format. What I would have really liked to see is human-readable content in a way that can be formatted from the command line. Doing all the formatting myself when there are other output formats that do it for you just was not worth it. Formatting also includes currency signs and such.

[simonmichael]

Are we talking about CSV output or JSON output ?

[MrPixelized]

We are talking about JSON output. CSV output gave me the data I wanted to have. It's just that as a (temporary) solution that was quicker than rolling my own rendering of the JSON output, I decided to go hledger -> csv -> json -> my thing instead.

[simonmichael]

Ok, that's totally fine. But I don't have a good understanding of the problems you mention. Here's how it seems to me:

• json output provides numbers with up to 10 decimal places. When reading JSON, I imagine you are usually in a programming language and can easily reformat those numbers.
• csv output provides machine-readable numbers, which I believe are still somewhat customizable with -c/--commodity-style. TSV is also available.
• text output provides human-readable numbers, with extreme customisability from the command line.

If you'd like to share more specifics, please do. Maybe there are solutions or problems we're not seeing.

[MrPixelized]

Well, the assumption "When reading JSON, I imagine you are usually in a programming language and can easily reformat those numbers." doesn't quite hold. Yes, I am in a programming language, and I could reformat those numbers, but it's actually quite a bit of extra implementation on top of what's otherwise just reading a block of extremely easily digestable data (in JSON) and making a report out of it. In my case, it was less work to use CSV as an intermediate and convert it to JSON than to implement the formatting. So, in a case where I might be forced to use JSON, another output format was still preferred.

[simonmichael]

I’m trying to find out, not to assume anything. :)

Long story short, are you saying it would be better for everyone if json numbers respected —-commodity-style ?

[MrPixelized]

I can't speak for everyone, but it would have helped my case if there would be (alongside the machine-targeted data), strings provided that behave as what would otherwise be presented to humans (e.g. the default output format).

Thanks for your engagement with this :)