I have an interesting quandry right now about price fetchers and timezones,
which explains why the build is broken.
I was a bit sloppy and never defined precisely the timezone of the input
date to the price fetcher (when you use bean-price ... -d <date>) nor what
ought to be the timezone of the date it outputs.
That's why it fails from Europe, for instance.

If you're in a timezone other than that of the market (e.g. you're located
in Japan and fetching the price of an instrument trading in the USA), what
should be the date that the price fetcher prints?

One school of thought (say, A) would be that the date should be that of the
market where the instrument is traded. One problem is that this is well
defined for stocks and bonds, but not so for FX / currency exchange rates.
So you end up treating these things differently (e.g., for FX you input and
output the date as of the user's timezone). Moreover, of the four price
sources I have, only Yahoo outputs the exchange's timezone. We can assume
IEX is all USA products. I wrote to Quandl about this - their instruments
are global and they don't provide a timezone. OANDA is all FX.

The other schools of though (say, B) would be that since all the
transactions are recorded in the user's timezone, the prices should be
printed with dates relative to that timezone. So a closing price at
2018-04-09 in the USA market might render as 2018-04-10 when fetched from
Tokyo (depending on the time it is fetched). This difference is somewhat
inelegant, but on the other hand it makes the treatment of timezones
consistent - you always convert date/timestamps from/to the user's timezone.

(B) is easy to implement and well-defined, but it means the dates may not
match that seen on the particular markets (though they always line up with
the user's transactions).
(A) is trickier to implement - each instrument has to have an associated
timezone and I have no authoritative source for that - but seems more

An idea to resolve (A)'s problems would be to use optional metadata on the
Commodity directives to let the user provide the timezone and if the
timezone isn't provided, to assume the instrument in the timezone of the
user and compute the date that way.

(I think a similar issue occurs about accounts. For instance, if you're in
Japan and you access an account in the US, do you use US dates? For sure
you do - especially if you use importers. It doesn't have the same impact
though, because inter-account transactions already have limbo time because
of posting vs. settlement dates.)

Any thoughts welcome. I lean toward (B), but I'm annoyed.

You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To post to this group, send email to beancount@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to