price.date, transaction.post_date and neutral time
Sébastien de Menten
sdementen at gmail.com
Tue Feb 13 07:47:01 EST 2018
On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel <
gnucash-devel at gnucash.org> wrote:
> On 12/02/2018 21:00, Sébastien de Menten wrote:
>> When I enter a new price for a given day for a security on the NASDAQ via
>> the price editor, it is stored in the date column the UTC time for that
>> at 00:00:00 local time (CET=Europe, not EST=New-York). Which is weird
>> because across timezone, the day of the price will be interpreted
> Are you entering the prices by hand ?
> indeed, "via the price editor" (source=user:price-editor in the prices
> But John R says "that's an absolute time anchored in the market's time
>> zone, not the user's. " which leaves me puzzled as for the example above
>> the NASDAQ it uses European time (i.e.my local time) not NASDAQ time. But
>> maybe when using the Perl finance quote program, there is a more complete
>> time information (incl the correct market timezone).
> If you are entering the prices yourself then it seems sensible to me the
> time is when you made the entry rather than the market's time.
> yes, indeed. John's comment made me doubt ...
if I use the price editor for today (source=user:price-editor), I get as
date 2012/02/12 23:00:00 (because I am in UTC+1)
if I edit a transaction for today on that commodity
(source=user:xfer-dialog), then I get as date 2012/02/13 10:59:00 (which is
the post_date of the transaction which uses GnuCash "neutral time" concept.
I haven't tried yet via the Finance:Quote as it doesn't install easily
under my setup (windows, non admin) but I would be curious to see what ends
up in the date column in this case.
> Also, unless you have a special arrangement with a broker, most people
> don't get a market price, it will be a bit under or over so the market
> price is just for reference once you include tx costs, etc.
> Anyway, my question was to understand the reasons of the encoding of a
>> day/date as an instant/datetime, reasons that are still a bit obscure
>> (except legacy issue)
> For most purposes it shouldn't matter. The prices db is independent of
> the actual transactions, it is used for working out the value of stuff and,
> as I am sure you are aware, the value of commodities changes every minute
> and second ... gnc is *never* going to keep up with that sort of price
> In retrospect it may be thought that the design mistake was including a
> time in the price db at all :)
That's exaclty my point ;-)
More information about the gnucash-devel