a16aecfa96
Why: big.Float is not an ideal type for dealing with monetary amounts, because no matter how high the precision, some non-integer decimal values can not be represented exactly in base-2 floating point. Also, storing gob-encoded big.Float values in the database makes it very hard to use those values in meaningful queries, making it difficult to do any sort of analysis on billing. For better accuracy, then, we can just represent monetary values as integers (in whatever base units are appropriate for the currency). For example, STORJ tokens or Bitcoins can not be split into pieces smaller than 10^-8, so we can store amounts of STORJ or BTC with precision simply by moving the decimal point 8 digits to the right. For USD values (assuming we don't want to deal with fractional cents), we can move the decimal point 2 digits to the right. To make it easier and less error-prone to deal with the math involved, I introduce here a new type, monetary.Amount, instances of which have an associated value _and_ a currency. Change-Id: I03395d52f0e2473cf301361f6033722b54640265 |
||
---|---|---|
.. | ||
coinpayments | ||
monetary | ||
paymentsconfig | ||
stripecoinpayments | ||
account.go | ||
balance.go | ||
charges.go | ||
coupons_test.go | ||
coupons.go | ||
creditcards.go | ||
credits.go | ||
invoices.go | ||
projectcharges.go | ||
tokens.go |