On Fri, Jan 27, 2017 at 2:48 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:

> On 1/27/17 8:17 AM, Brad DeJong wrote:
>> Add the potential for regulatory requirements to change at any time -
>> sort of like timezone information. So no hard coded behavior.
> Well, I wish we had support for storing those changing requirements as
> well. If we had that it would greatly simplify having a timestamp type that
> stores the original timezone.
> BTW, time itself fits in the multi-unit pattern, since months don't have a
> fixed conversion to days (and technically seconds don't have a fixed
> conversion to anything thanks to leap seconds).

I agree with Jim here.

I think we don't need to solve all the possible currency problems to have a
useful type. I'll reiterate what I think is the key point here:

A currency type should work like a wallet. If I have 20USD in my wallet and
I put 20EUR in the wallet, I have 20USD and 20EUR in the wallet, not 42USD
(or whatever the conversion rate is these days). If I want to convert those
to a single currency, I need to perform an operation.

If we had this as a basic building block, support for some of the major
currency formats, and a function that a user could call (think of the way
we justify_interval sums of intervals to account for the ambiguities in day
lengths and so on), I think we'd have a pretty useful type.

As to Tom's point, conversion rates do not vary with time, they vary with
time, space, vendor, whether you're buying or selling, and in what
quantity, and so on. We can give people the tools to more easily and
accurately execute this math without actually building a whole financial
tool suite in the first release.

I'll also note that in the absence of progress here, users continue to get
bad advice about using the existing MONEY type such as here:

Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt."—Kurt Vonnegut

Reply via email to