price.date, transaction.post_date and neutral time

[Sébastien de Menten]

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
>> day
>> 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
>> differently.
>>
>
> Are you entering the prices by hand ?
>
> indeed, "via the price editor" (source=user:price-editor in the prices
table)


> 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
>> on
>> 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
> change.
>
> 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 ;-)