18 ms·
C# has a decimal type: "The decimal type is a 128-bit data type suitable for financial and monetary calculations." https://learn.microsoft.com/en-us/dotnet/csh
by yett 2y ago
C# has a decimal type: "The decimal type is a 128-bit data type suitable for financial and monetary calculations."
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/types#838-the-decimal-type https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
- nsxwolf 2y agoThat provides the basis for solving precision and rounding issues but for a money library you need more abstractions. The ability to assign a currency code and supply conversion rates and convert between currencies at a minimum.
- tightbookkeeper 2y agoThat’s an application design choice, not a minimum. An alternative is to work internally in one unit and convert at format time.
- maest 2y agoThat is not a viable alternative.
- serial_dev 2y agoEven though my gut reaction is to agree with you, it’s true that it is an app design decision, so in certain scenarios it might very well be a good design decision.
- tightbookkeeper 2y agoShipped applications disagree with you.
- dmoy 2y agoIt really depends on the context of the app Sometimes you can do all calculations in a single currency and convert at reporting time. I've worked on teams where that was fine. Sometimes... you really cannot do that.
- tightbookkeeper 2y agoCompletely agree.
- Phrodo_00 2y agoMight be a minimum for a money library (not completely sure what the absolute minimum would be). It would be an application design choice to not use one and stick to general fixed point/Big Num constructs.
- V41frQo1SccpfHI 2y agoOut of curiosity, how do you deal with changing exchange rates in that case?
- amoshebb 2y agoit depends, if it was a currency exchange, it'll be labeled in one of 3 ways, either average rate per unit, absolute, or it'll be a reference to a MSSQL table containing exceptional spot transactions. Otherwise, a complete history of exchange rates is stored in KDB, most days you can take the average, and for small amounts on weekends or days the exchange is closed you can just interpolate, there's also a half dozen XLSXs full of certain exceptional days, so you'll have to check that you're not on one of those lists. Then if you're not dealing with USD->X or CAD->USD->X things start to get hairy.
- tightbookkeeper 2y agoYou never want to be lossy with user inputs. Save what they told you and then convert for internal logic. The OP just described a language feature where you want to multiply euros with usd one place and yen and dinar in another. You don’t need to do that which is why a decimal or 64 bit int is a fine language approach.
- knodi123 2y agoWe store all our financial data in Greenwich Mean Dollars.
- irq-1 2y agoWhat are you going to do about the new Moon Dollars?
- epolanski 2y agoAlso, avoid making errors like summing different currencies.
- moomin 2y agoThe thing is, it doesn’t really help. A system I’m working on can have hundreds of monetary amounts in the same currency. Storing the currency against each one is an awful waste of space. Equally the allocation trick is good, but you’ll find that the people who really care about this stuff really care about the exact algorithm you’re using and who it favours.
- eriksencosta 2y agoI think it helps to have the inputs and outputs of the system fully representing a "money" (i.e., a monetary amount + its currency code in places like API resources, events, and so on). This way you can internationalize or support multi-currency processing if that's the case. That's (if I remember correctly) what the payment card services companies (e.g., Mastercard, Visa) do by default in their message exchanges when calling the issuer for transaction confirmation. Anyway, the allocation may be tweaked to favour where the additional/missing pennies will be allocated. You can find more at: https://github.com/eriksencosta/money/blob/trunk/docs/usage/allocation.md https://github.com/eriksencosta/money/blob/trunk/docs/usage/...