, transaction.post_date and neutral time

David T. sunfish62 at
Tue Feb 13 21:59:19 EST 2018

Wm, Sebastien,

I profess to not paying too much attention to this thread, but IIRC, there was a time when the price entered into transactions was NOT entered into the price DB, which meant that users would often get useless reports on commodities, since the reports use price DB entries to calculate figures. The workaround was to add transaction-generated prices to the Price DB as well, thus (seemingly) killing two birds with one mouse click. I suspect that when John did work to decide on a new timezone neautral solution to the timestamp issue, he didn’t adjust this code as well.

Given the nature of these entries (i.e., added from the transaction to document a price that was valid at some arbitrary point in the past), I don’t see how a specific time could be added (as it might be with F::Q prices). Ditto manually-added prices.


> On Feb 14, 2018, at 3:19 AM, Wm via gnucash-devel <gnucash-devel at> wrote:
> On 13/02/2018 18:12, Sébastien de Menten wrote:
>> r/2012/2018/ (it was a typo)
> ok
>> My point is that a price entered via the price editor (manually) is handled
>> differently than a price generated via a transaction 
> Isn't that a good thing ? I shouldn't have to say again that the price db is just for reference, it doesn't change the tx just their valuations at a point in time for reporting purposes.  From a strict accounting POV gnc doesn't need the price db at all because you are allowed to value your assets at however much you want.  The tax lady may disagree, of course :)
> > > and may be (haven't
>> tested) different than a price downloaded via the Finance:Quote module.
> It will almost certainly be different, different exchanges have different prices, there are people that make a lot of money noticing the small differences between exchanges and trading based on those differences.
>> And indeed, as the time component is meaningless (yet different in function
>> on the price creation method), it shouldn't be stored OR, if for legacy
>> reason it should be kept, it could at least be stored consistently (across
>> price creation method) using for instance the "neutral time" approach used
>> for the post_date.
>> If not, any extract of price data (direct SQL, XML, piecash, ...) is
>> complex to use.
> I don't see the complexity. Why don't you just discard the time component as it is essentially meaningless after 24 or 48 hours ?
> Isn't your typo a good observation in that it shows that time isn't the significant part of the price record ?
> P.S. I don't like arguing with you, Sebastien, it is better when we agree :)
> -- 
> Wm
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list