在阅读了如何正确优化 handle users in multiple timezones 之后，我了解到要走的路是将所有日期存储在一个规范化的应用程序范围的时区 - UTC 然后应用规范化时区之间的差异以及输出时的个人用户时区。今天我开始思考是否适合将这种方法应用于处理软件中的货币：
所有存储的货币都转换为应用程序范围的货币，比如说EUR (€)，并且在输出时，该货币将转换回用户自己的货币，并更新当天的汇率？
这里有什么常识？这通常是如何解决的？在选择处理方法之前我应该注意什么？
【问题讨论】：
标签： currency currency-exchange-rates
一种标准方法是在持有和操纵货币价值时同时存储金额和货币。
请参阅 Martin Fowler 的企业应用程序架构模式中的 Money Pattern。
Fowler 描述了定义一个简单的数据类型来保存两个原始组件，以及用于执行货币操作的重载算术运算符：
“基本思想是有一个 Money 类，其中包含数字字段 金额和货币。您可以将金额存储为 整数类型或固定十进制类型。十进制类型更容易 一些操作，其他人的积分。你绝对应该 避免任何类型的浮点类型，因为这会引入类型 Money 旨在避免的舍入问题。大多数时候 人们希望货币价值四舍五入到最小的完整单位， 比如美元中的美分。但是，有时分数 需要单位。重要的是要明确什么样的钱 您正在使用，尤其是在同时使用两者的应用程序中 种。对于这两种情况有不同的类型是有意义的 它们在算术中的表现完全不同。
Money 需要算术运算，以便您可以将 money 对象用作 使用数字时很容易。但是货币的算术运算有 货币操作在数量上的一些重要差异。最多 显然，任何加法或减法都需要有货币意识，所以 如果您尝试将不同的钱加在一起，您可以做出反应 货币。最简单、最常见的反应是治疗 将不同的货币加在一起是错误的。在多一些 复杂的情况，你可以使用 Ward Cunningham 的金钱观念 包。这是一个包含多种货币的对象 一起在一个对象中。然后这个对象可以参与 计算就像任何货币对象一样。它也可以被评价为 货币。”
【讨论】：
处理时间和货币之间的区别在于时区不会改变价值。
在处理货币价值时，您必须考虑实际货币的货币是什么。如果实际货币是美元，而您将其存储为欧元，那么当它们的值发生变化时，您会发现实际值和存储值之间存在差异。
或者，当汇率更新时，您必须重新计算所有值，但这会失去以单一货币存储值的目的。
【讨论】：