> 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.

▲

afavour 5 hours ago | parent | next [-]

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

	▲	andylynch 4 hours ago \| parent [-]
		I’ve seen bugs like this in prod systems. The notional value of the error tends to make the people concerned anything but silent.

▲

microgpt 6 hours ago | parent | prev | next [-]

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

▲

lxgr 4 hours ago | parent | next [-]

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.

▲

denismenace an hour ago | parent | prev | next [-]

Currency: USD Amount: 99500 Decimals: 5

▲

snsnsjjsjsiisa 3 hours ago | parent | prev | next [-]

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

▲

xprnio 5 hours ago | parent | prev [-]

Round it up

	▲	microgpt 4 hours ago \| parent [-]
		Charge $0.995 Refund $1.00 Repeat

▲

xlii 7 hours ago | parent | prev | next [-]

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

	▲	lxgr 7 hours ago \| parent [-]
		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").

▲

lxgr 8 hours ago | parent | prev [-]

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

▲

makeitdouble 7 hours ago | parent [-]

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 ?)

	▲	lxgr 7 hours ago \| parent [-]
		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.