Hacker News Reader

Comment by denismenace | Hacker News Reader

> but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of digits for a given currency

Why would that be a problem? You just transform the values when interacting with their API.

View on HN

Exactly, model is in integers and representation can be 1⃣3⃣ or whatever, that's why model-view separation exist.

Sure, you can do that if you can absolutely guarantee that everyone will always respect that separation and there will never be ambiguity between your internal and some partner's representation – even during incidents, even during low-level CSV-to-DB ETLs during incidents ("just one time, I promise, we don't have time to build the proper adapter, but look how similar their and our formats are").

In places where it matters the fines are so high, that everyone are stickler to the rules. It's like a hot oven - not merely a warning of risk. It's actual risk which was touched and which burned.

If an adapter would put your yearly salary at risk (not an exaggeration) would you quicken it?

Customer was charged $0.995 after fees, how to represent in your data model with integer cents?

Round it up

Charge $0.995

Refund $1.00

Repeat

Charge $0.995

Charge Actual $1.00

Refund $1.000

Alternately

Charge $0.995

ERROR CHARGE AMOUNT MUST BE ROUNDED TO NEAREST CENT

In my scenario your payment gateway added a $0.005 fee. You told it $0.99.

You'll have to decide when and how to round. Keeping individual billing items at high precision and rounding after summing them up can work; defining and documenting a rounding policy (or complying with whatever's legally required in your jurisdiction/domain) and rounding each individual billed item can as well.

You use 1/1000th or 1/10000th or whatever you need. You do not need “cents”.

Currency: USD Amount: 99500 Decimals: 5

Congrats m8 you invented floating point

Then you have no idea how floating point works. (Hint: its in the name)

How is the client going to pay that? They can't be charged half a cent.

Because a lot of the time there won’t be any error when you’re wrong, just silent data loss.

I’ve seen bugs like this in prod systems. The notional value of the error tends to make the people concerned anything but silent.

Sure, but are all your (and your users' and vendors') engineers and LLM agents going to remember that? When in doubt, always be explicit.

I'm curious how you handle that.

Let's say I operate with a 4 decimal expectation and your API expects 6, is there any way to reconcile that outside of documentation and or metadata ? (which would be the same issue I guess whatever representation is used ?)

Yeah, you need to document it.

Still, even if you do: Chances that your users are just going to assume you're conforming to ISO 4217, some national standard, or your competitor that they're already integrated with are pretty high, so I wouldn't take the chance. Pick something that doesn't have to be documented instead.

Reply on news.ycombinator.com