5 ms·
> 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 gi
by denismenace 3mo ago
> 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.
- lxgr 3mo agoSure, but are all your (and your users' and vendors') engineers and LLM agents going to remember that? When in doubt, always be explicit.
- makeitdouble 3mo agoI'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 3mo agoYeah, 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.
- xlii 3mo agoExactly, model is in integers and representation can be 1⃣3⃣ or whatever, that's why model-view separation exist.
- lxgr 3mo agoSure, 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").
- xlii 3mo agoIn 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?
- microgpt 3mo agoCustomer was charged $0.995 after fees, how to represent in your data model with integer cents?
- xprnio 3mo agoRound it up
- microgpt 3mo agoCharge $0.995 Refund $1.00 Repeat
- SJC_Hacker 3mo agoCharge $0.995 Charge Actual $1.00 Refund $1.000 Alternately Charge $0.995 ERROR CHARGE AMOUNT MUST BE ROUNDED TO NEAREST CENT
- microgpt 3mo agoIn my scenario your payment gateway added a $0.005 fee. You told it $0.99.
- lxgr 3mo agoYou'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.
- snsnsjjsjsiisa 3mo agoYou use 1/1000th or 1/10000th or whatever you need. You do not need “cents”.
- denismenace 3mo agoCurrency: USD Amount: 99500 Decimals: 5
- afavour 3mo agoBecause a lot of the time there won’t be any error when you’re wrong, just silent data loss.
- andylynch 3mo agoI’ve seen bugs like this in prod systems. The notional value of the error tends to make the people concerned anything but silent.