Common sense when storing currencies?

Question

After reading up on how to best handle users in multiple timezones properly, I've learned that the way to go is to store all dates in an normalized, application-wide timezone - UTC and then apply the diff between the normalized timezone and the individual users timezone when outputting. Today I came to think if this would be appropriate to apply this approach to handling currency in software:

All stored currency are converted to a application-wide currency, lets say EUR (€), and when outputting, the currency is converted back into the users own currency, with an updated exchange rate of the day?

What's common sense here? How is this generally solved and what should I be aware of before choosing a way to handle this?

Solubilize

Similar question: https://mcmap.net/q/432802/-money-data-type-for-net – Moxie

Tell us more about the application. If you are handling eeal money, I would hate to see the balance I put in today be less money tomorrow. In fact, that would probably be illegal in many jurisdictions. – Dyun

eeal? real? Yep, I thought about that as an upcoming issue, but I have not yet figured out a solution... – Solubilize

Answer 1

One standard approach is to store both an amount and a currency whenever monetary values are held and manipulated.

See the Money Pattern in Martin Fowler's Patterns of Enterprise Application Architecture.

Fowler describes defining a simple datatype to hold the two primitive components, with overloaded arithmetical operators for performing monetary operations:

"The basic idea is to have a Money class with fields for the numeric amount and the currency. You can store the amount as either an integral type or a fixed decimal type. The decimal type is easier for some manipulations, the integral for others. You should absolutely avoid any kind of floating point type, as that will introduce the kind of rounding problems that Money is intended to avoid. Most of the time people want monetary values rounded to the smallest complete unit, such as cents in the dollar. However, there are times when fractional units are needed. It’s important to make it clear what kind of money you’re working with, especially in an application that uses both kinds. It makes sense to have different types for the two cases as they behave quite differently under arithmetic.

Money needs arithmetic operations so that you can use money objects as easily as you use numbers. But arithmetic operations for money have some important differences to money operations in numbers. Most obviously, any addition or subtraction needs to be currency aware so you can react if you try to add together monies of different currencies. The simplest, and most common, response is to treat the adding together of disparate currencies as an error. In some more sophisticated situations you can use Ward Cunningham’s idea of a money bag. This is an object that contains monies of multiple currencies together in one object. This object can then participate in calculations just like any money object. It can also be valued into a currency."

Visualize

The summation of this would be: convert to a common currency only for purposes of manipulating two different currency types in the same transaction, and only for the duration of that transaction. – Dramatic

Answer 2

The difference between handling time and currency, is that time zones doesn't shift in value.

When handling monetary values you have to consider what the currency of the actual money is. If the actual money is in USD and you store it as EUR, you will get a discrepancy between the actual value and the stored value when their values shift.

Alternatively you would have to recalculate all values when the exchange rate is updated, but that would take away the purpose of storing the values in a single currency.

Ieyasu