3 ms·

How would you deal with exchange rate, which changes in real time?

farazzz 8y ago
From the docs > You must provide your own API to retrieve exchange rates. https://sarahdayan.github.io/dinero.js/module-Dinero.html#~convert https://sarahdayan.github.io/dinero.js/module-Dinero.html#~c...
zachrose 8y ago
In the lazy version i have suggested, the exchange rates are deferred until you “need to know” and the sum is converted into a concrete currency. If you’re keeping these values around in memory for an extended period of time time and you care about rapid changes to exchange rates, then you have a complex domain and the deferred exchanges may or may not be a good fit, but at that point you need larger system design, not a JavaScript library. Also in my dream money library, division and multiplication would be done with whole number fractions like new Dinero({amount: 1000, currency: ‘usd’}) .multiply({numerator: 1, denominator: 3 }) which can similarly be deferred to prevent rounding errors in partial calculations.
- willbw 8y ago
  But say the euro goes down 50% against the USD, then you are probably going to want differing amounts of those currencies right? I think generally you 'need to know' immediately.
- kchoudhu 8y ago
  You need a timestamp and a timeseries database of exchange rates so that you can go back in time and reconstruct your calculations at a latter date as well. Source: worked at a bank that implemented pretty much this.
  - swish_bob 8y ago
    To multiple different currencies at multiple valuation points. With optional exchange rate costs. It's a pain in the arse ... Source: worked on multi-currency fund tracking software.
    - zachrose 8y ago
      Agreed with both of you, and using an exchange rate at a specific point in time actually could make deferring that calculation even more of a sound idea, depending on the exact semantics of what you’re computing. At larger scales even exchange rates are a leaky abstraction over a forex market, so there you go. No solution will work everywhere. But if you’re entering the prices of last week’s coffee and hotel room into a web app to see how much you’ll be reimbursed, you don’t want to use a new exchange rate every time a form input changes. Source: worked on multi-currency expense reporting software where everything is done in JavaScript floats.
      - kchoudhu 8y ago
        We should all start a club defined by our forex market induced alcoholism.
        zachrose 8y ago
        The only rule is no splitting the bill
- village-idiot 8y ago
  I’d rather keep the IO call to determine exchange rate far away from my arithmetic, personally. This technique is fantastic for units that don’t change relations though, like mass and length.

From the docs > You must provide your own API to retrieve exchange rates. https://sarahdayan.github.io/dinero.js/module-Dinero.html#~convert https://sarahdayan.github.io/dinero.js/module-Dinero.html#~c...

zachrose 8y ago

In the lazy version i have suggested, the exchange rates are deferred until you “need to know” and the sum is converted into a concrete currency. If you’re keeping these values around in memory for an extended period of time time and you care about rapid changes to exchange rates, then you have a complex domain and the deferred exchanges may or may not be a good fit, but at that point you need larger system design, not a JavaScript library. Also in my dream money library, division and multiplication would be done with whole number fractions like new Dinero({amount: 1000, currency: ‘usd’}) .multiply({numerator: 1, denominator: 3 }) which can similarly be deferred to prevent rounding errors in partial calculations.

willbw 8y ago
But say the euro goes down 50% against the USD, then you are probably going to want differing amounts of those currencies right? I think generally you 'need to know' immediately.
kchoudhu 8y ago
You need a timestamp and a timeseries database of exchange rates so that you can go back in time and reconstruct your calculations at a latter date as well. Source: worked at a bank that implemented pretty much this.
- swish_bob 8y ago
  To multiple different currencies at multiple valuation points. With optional exchange rate costs. It's a pain in the arse ... Source: worked on multi-currency fund tracking software.
  - zachrose 8y ago
    Agreed with both of you, and using an exchange rate at a specific point in time actually could make deferring that calculation even more of a sound idea, depending on the exact semantics of what you’re computing. At larger scales even exchange rates are a leaky abstraction over a forex market, so there you go. No solution will work everywhere. But if you’re entering the prices of last week’s coffee and hotel room into a web app to see how much you’ll be reimbursed, you don’t want to use a new exchange rate every time a form input changes. Source: worked on multi-currency expense reporting software where everything is done in JavaScript floats.
    - kchoudhu 8y ago
      We should all start a club defined by our forex market induced alcoholism.
      - zachrose 8y ago
        The only rule is no splitting the bill
village-idiot 8y ago
I’d rather keep the IO call to determine exchange rate far away from my arithmetic, personally. This technique is fantastic for units that don’t change relations though, like mass and length.