Hacker News Reader

Comment by b203 | Hacker News Reader

There are some painpoints that are being addressed:

1) timestamp : I have had issues with a round-tripping timestamp representation quite a bit 2) decimal : currency is denoted in decimal rather than float and shows the Amazon retail heritage. This is very useful. 3) symbols : I've had cases where symbol table/dictionary would have made big difference in serialized size

View on HN

Re time stamp and decimal, probably no surprise that it is used heavily by QLDB, where having a very clear time for a change is important and a common use case is logging debits and credits as a financial ledger.

See Zish for an improved JSON:

https://github.com/tlocke/zish

It has timestamps and decimals. Full disclosure, I am the author.

I think using decimals (or arbitrary size integers) for currency is common knowledge by now.

I don't know. It was common knowledge for me in college (as in it was taught as part of the curriculum) but as far as I can tell in the intervening 30+ years that knowledge seems to have been lost and relearned many times over.

Terrifyingly, I discovered recently that Plaid’s API uses floats instead of decimal. For example, security prices:

https://plaid.com/docs/#security-schema

cash values should be represented in fixed precision to maintain the integrity of the transaction and your book, while the prices for securities represent something different.

In securities transactions, the quantity and quote are critical. You aren’t buying securities from Plaid, right?

If you try to liquidate or resize based on the Plaid quote, your brokerage or counterparty is going to provide a totally different quote, and one from a system engineered to provide quotes aligned exactly to the market standards.

I don’t see the risk/terror.

Reply on news.ycombinator.com