Oh, this reminds me of my first job out of college at a Swiss bank. Apparently every time a currency conversion was done in a particular model, there was a routine that translated back and forth between the pre-Euro currency and Euro at the conversion rate. So a USD-EUR transaction with a party in France would be run as USD-FRF --> FRF-EUR. All in COBOL. As a result, every so often, you'd get a slightly different result running a USD-EUR trade with a party in France versus e.g. Germany or the U.K.

So what happened when those discrepancies arose?

They became the basis for the plot of Superman III

> what happened when those discrepancies arose?

They were just passed along.

You could say the same of Unicode, though. Some cultural abstractions become increasingly rigid because they’re embedded in computer systems everywhere.

Yes, and sometimes the context is not just social but legal or contractual, e.g. rounding currency.

Yes, and rounding currency is just something that is always handled, as is the number of places that you take a currency out to - for example, gas is often priced at thousandths of a dollar rather than hundreds but presented to the customer in hundredths at the end. Or Yen in most cases does not have a decimal point, except that the places where you round or don't round can be consequential in large enough quantities.

These are largely things that can be handled by a library, but if it's in the language you best not get it wrong because it's so much harder to change!

From my perspective those are tenths of a cent. Stripe has integer values for cents.

Am I wrong here?

https://stackoverflow.com/questions/35326710/stripe-currency...

This. But more than being changeable they (time and money) are supra-logical or trans-rational. In other words, computers are limited to what can be modeled or calculated with the one logical operation (it has lots of names, I like "Quine dagger") but these phenomenon are not.

There's two problems with currencies:

1. So many languages don't have a native "decimal" type to build off of, so somewhere in the data's lifecycle, a "1.75" turns into "1.7499999999997".

2. The rules around exchange rates, number of decimals, coding and symbols.

The first problem should be solved as a first-class language feature. This will discourage hacks with a "fixed point" type, where you store integer "175 cents" instead of decimal "$1.75"-- inviting huge confusion if the currency ever drops or restructures its minor unit, and supports non-money use cases where floating point inaccuracy is risky.

Item 2 makes more sense as a library. You can record that there's a 1000:1 ratio between pre-1998 and current roubles, that the symbol for the Baht will inevitably confuse Bitcoin enthusiasts, and that the Korean won no longer has any decimal places, in dynamic fields.