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 coherent. 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 firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOE6K9bCmsA6cwmBuRMPPPXHnbCY140HM0HLKvnnE45SQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.