Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 14/02/2018 02:59, David T. via gnucash-devel wrote:

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.


IIRC it was meant to be one price per commodity per date [1]



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.


The understanding required is that the price db is occasional to 
transactions.


A real life tx may create a record in the price db, however, it was also 
discussed and decided that there would only be one price per commodity 
in the price db per day.


From an accounting pov it doesn't matter which price was recorded 
yesterday as valuations depend on tax people, local accounting 
conventions, etc. and they mainly want consistency.


[1] I don't think the gnc price db is suitable [2] for trading intra day 
simply because the price sources are too unreliable (many apps use F::Q) 
and because exchanges put delays on prices, etc. it just isn't 
practical.  It is a square peg in a round hole issue for me.


[2] further, if you did want to record prices in more detail, there are 
other free ways of doing it without cramming your gnc db with stuff that 
is completely impersonal to you.  Remember, the price you bought or sold 
at is what counts and as a punter you are very unlikely to get the big 
market price anyway.


--
Wm






___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 14/02/2018 10:58, Mark Haanen wrote:

Wm via gnucash-devel schreef op 13-02-18 om 17:10:

On 13/02/2018 09:12, Alen Siljak wrote:


- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, 
Direct Bond, favorite company ABC stock, etc.

- we link the investments (by symbol) to the allocation classes above.
   Stocks Fund => stocks
   Bonds Fund => bonds
   Direct Bond => bonds
   ABC => stocks
- we get the latest prices


That's looking self referential to me as your plan allows for a 1.75% 
government bond to be called a stock and a stock to be called a bond.


all a bit pointless.

All that computer software needs to do (and, deep into 21st century 
this is the least I'd expect my personal finance app to do) is to 
calculate the current value of the holdings, therefore asset classes, 
and say:
"you have 50K in investments, out of which 30% is in stocks and 70% 
in bonds, while your allocation is 10%/90%".


Isn't that just back referencing ?

I own a dog, I check my dog ownership and find I own a dog.

Neither I or the dog should be surprised. 


Not really, because the value of the portfolio assets (and therefore the 
value of the different asset classes) change over time.


But not as much as you suggest.

Say my target asset allocation is 10%/90% (as above) and that is the 
ratio in which I divide the amount I use buying my assets (say $100).
However, I don't own $90 of stocks, but rather 2 stock units priced at 
$45. The same for my bond assets (e.g. half a bond currently priced at 
$20).


Over time the prices of the underlying assets in my portfolio change.
For instance, during recession and with quantitative easing in place, 
bond prices climbed while equity prices dropped.##


Except they haven't.  you should *not* expect gnc to do predictive 
pricing.  that is an absolute NO NO NO


So now my 2 stock units are only worth $60 total, while my bond category 
assets climbed to $30.


But that is only in your mind.  My stocks and bonds didn't do that!

All that Alen is saying that he wants a report which compares my target 
ratio of 10/90 with my current value ratio of 33/67, as this may lead to 
a rebalancing of the portfolio.


I am able to say that we do not actually give investment advice.  Usual 
reasons.



I'm thinking at 10 stocks and 90 bonds (without knowing the currency or 
market) it is just a rip off or it is a portfolio for a person that is 
about to die.

==
yeah, I know a senior can whack me for this, but it is in conversation, 
so ... 33 / 67 is super conservative I'd check the switching costs. 
That is how the sales person gets their money.

=

If Mark Haanen / Alen Siljak or anyone else related to them is in a 
client / professional relationship I think we should know.


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Mark Haanen]

Wm via gnucash-devel schreef op 13-02-18 om 17:10:

On 13/02/2018 09:12, Alen Siljak wrote:


- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, 
Direct Bond, favorite company ABC stock, etc.

- we link the investments (by symbol) to the allocation classes above.
   Stocks Fund => stocks
   Bonds Fund => bonds
   Direct Bond => bonds
   ABC => stocks
- we get the latest prices


That's looking self referential to me as your plan allows for a 1.75% 
government bond to be called a stock and a stock to be called a bond.


all a bit pointless.

All that computer software needs to do (and, deep into 21st century 
this is the least I'd expect my personal finance app to do) is to 
calculate the current value of the holdings, therefore asset classes, 
and say:
"you have 50K in investments, out of which 30% is in stocks and 70% 
in bonds, while your allocation is 10%/90%".


Isn't that just back referencing ?

I own a dog, I check my dog ownership and find I own a dog.

Neither I or the dog should be surprised. 


Not really, because the value of the portfolio assets (and therefore the 
value of the different asset classes) change over time.


Say my target asset allocation is 10%/90% (as above) and that is the 
ratio in which I divide the amount I use buying my assets (say $100).
However, I don't own $90 of stocks, but rather 2 stock units priced at 
$45. The same for my bond assets (e.g. half a bond currently priced at $20).


Over time the prices of the underlying assets in my portfolio change.
For instance, during recession and with quantitative easing in place, 
bond prices climbed while equity prices dropped.
So now my 2 stock units are only worth $60 total, while my bond category 
assets climbed to $30.
All that Alen is saying that he wants a report which compares my target 
ratio of 10/90 with my current value ratio of 33/67, as this may lead to 
a rebalancing of the portfolio.


-- Mark
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[David T. via gnucash-devel]

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.

Cheers,
David


> On Feb 14, 2018, at 3:19 AM, Wm via gnucash-devel  
> 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@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

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@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Sébastien de Menten]

r/2012/2018/ (it was a typo)
My point is that a price entered via the price editor (manually) is handled
differently than a price generated via a transaction and may be (haven't
tested) different than a price downloaded via the Finance:Quote module.
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.

On Feb 13, 2018 15:47, "Wm"  wrote:

> On 13/02/2018 12:47, Sébastien de Menten wrote:
>
>> On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel <
>> gnucash-devel@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)
>>
>
> OK, I'm not seeing the problem.  Isn't gnc behaving as expected ?
>
> 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
>>
>
> Oh, ffs.  Sebastien are you really entering prices from 5 years ago ???
> by hand ???
> and wondering about the fucking time ???
>
> I have respect for you.  Please have some respect for yourself and how
> other people regard you.
>
> 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.
>>
>
> If I look at my raw xml file F::Q gives me
> ===
> 
>   2018-02-09 12:00:00 +
> 
> ===
> which is correct, does everyone get something different ?
>
> I say, if you are entering by hand it *should* be the entry time not the
> market time.
>
> 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 ;-)
>>
>
> OK, Mr SdM are you saying the point is that there shouldn't be a time at
> all ?
>
> If so I think John said he'll get around to fixing that as and when.  I
> don't see the point in arguing about an hour or two 5 years ago which seems
> to be what you started :(
>
> --
> Wm
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 13/02/2018 09:12, Alen Siljak wrote:


Done. https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices


sweet


Aside: I am completely confused how MMEX for Android could be used for
Asset Allocation, MMEX doesn't understand Assets and Liabilities and
Equity!  Looking at the forums, the dev's of MMEX haven't realised that
prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for
Android app is moving beyond MMEX itself and may be working better with
gnc then please let us know,


It's very simple really. MMEX schema supports Asset and Investment accounts. 
For me, AA is really very simple:

- we set the allocation. I.e. 10% stocks, 90% bonds.


wow, you're a lot older than I expected if your stock / bond allocation 
is usual, damn near dead or very unforgiving about the world's economies



- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, Direct Bond, 
favorite company ABC stock, etc.
- we link the investments (by symbol) to the allocation classes above.
   Stocks Fund => stocks
   Bonds Fund => bonds
   Direct Bond => bonds
   ABC => stocks
- we get the latest prices


That's looking self referential to me as your plan allows for a 1.75% 
government bond to be called a stock and a stock to be called a bond.


all a bit pointless.


All that computer software needs to do (and, deep into 21st century this is the 
least I'd expect my personal finance app to do) is to calculate the current 
value of the holdings, therefore asset classes, and say:
"you have 50K in investments, out of which 30% is in stocks and 70% in bonds, while 
your allocation is 10%/90%".


Isn't that just back referencing ?

I own a dog, I check my dog ownership and find I own a dog.

Neither I or the dog should be surprised.


Asset Allocation is indeed simple, the problem is that no two people
agree on how to do it :)

Further, most AA models are USA biased, I don't think gnc needs any more
USA bias and any model that includes a stock allocation along the lines
of "domestic / foreign" is rubbish if you live outside of the USA so
let's not go there! [1]


OK. This is an interesting distinction. Are we talking about AA as a concept or a concrete AA implementation (values)? 


I think reality is preferable, I have actual money and presume you do too.


This is kinda class/instance relationship. I'm strictly interested in providing 
a tool that allows working with AA as a concept, and leave the actual 
implementation to the user.


hmmmn.  why?


They can work out their allocations in any way they prefer but the tool should 
be accessible and use the portfolio data from a GC book.
Just like a text editor, it does not tell you how to write but lets you write 
some text, save it, view/edit it later, and share it with someone else.


If you aren't really interested in doing stuff how about you fuck off 
and stop bothering people ?  Has it occurred to you that AA is a real 
thing for real people ?



for a sanity check, I am certain the good people that maintain the code
that allows us to get prices do *not* try to maintain a complete db of
prices themselves.  there is, quite simply, too much information.


Nobody mentioned a complete db of prices but separating Price information from the rest of the book. 


gnc does that anyway.


Prices are expendable and, as you say, can be retrieved independently. As they 
are independent of a book, they can be shared across multiple books and/or 
applications. Which is where I'm coming from. And price information is pretty 
much the same for any application. It has basic properties of Date(/Time), 
Symbol, and Value.


that isn't a discovery.


you haven't been looking, there are hundreds of AA implementations,
maybe you mean you haven't found many that agree with your
preconceptions ? AA is often about preconceptions.


Good advice. I see a few implementations, thanks to Python being so accessible. 
However, it seems that most of them are dealing with calculating an optimal 
allocation rather than letting the user manage it, the way ledger-cli (or MMEX 
4 Android) does.


nope, I think you misunderstand AA models entirely


Heh, you just outed yourself as a bad trader :)  A "good" trader doesn't
care about capital gains :)


I don't really. But I have to report on it to the tax authorities every year. ;)

On a side note, I'm pretty amazed how few people are interested in AA 
considering that they are the masters of their own fortune in countries with 
private pension funds. In countries like Australia, each person is responsible 
for choosing their superannuation fund, including the asset allocation.



Alen, I think someone is going to say "get a room, you two" fairly soon 
as we are definitely drifting off topic.  I think I still have a MMEX 
forum account from a while ago so maybe we can meet there.  They won't 
have a clue what we are talking about but do you care?


--
Wm

___
gnucash-devel mailing list

Re: price.date, transaction.post_date and neutral time

[Wm]

On 13/02/2018 12:47, Sébastien de Menten wrote:

On Tue, Feb 13, 2018 at 6:32 AM, Wm via gnucash-devel <
gnucash-devel@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)


OK, I'm not seeing the problem.  Isn't gnc behaving as expected ?


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


Oh, ffs.  Sebastien are you really entering prices from 5 years ago ???
by hand ???
and wondering about the fucking time ???

I have respect for you.  Please have some respect for yourself and how 
other people regard you.



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.


If I look at my raw xml file F::Q gives me
===

  2018-02-09 12:00:00 +

===
which is correct, does everyone get something different ?

I say, if you are entering by hand it *should* be the entry time not the 
market time.



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 ;-)


OK, Mr SdM are you saying the point is that there shouldn't be a time at 
all ?


If so I think John said he'll get around to fixing that as and when.  I 
don't see the point in arguing about an hour or two 5 years ago which 
seems to be what you started :(


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 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@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 ;-)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

> Sent: Tuesday, February 13, 2018 at 8:13 AM
> From: "Wm via gnucash-devel" <gnucash-devel@gnucash.org>
> To: gnucash-de...@lists.gnucash.org
> Subject: Re: price.date, transaction.post_date and neutral time
>
> That is interesting.  There has been quite a lot of enthusiasm for 
> mobile / gnc interaction.  Have you written about this before and I 
> missed it ?  If MMEX for Android is working well with gnc I think you 
> should make a wiki entry and ignore my view on MMEX as an accounting app.

Done. https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices

> Aside: I am completely confused how MMEX for Android could be used for 
> Asset Allocation, MMEX doesn't understand Assets and Liabilities and 
> Equity!  Looking at the forums, the dev's of MMEX haven't realised that 
> prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for 
> Android app is moving beyond MMEX itself and may be working better with 
> gnc then please let us know,

It's very simple really. MMEX schema supports Asset and Investment accounts. 
For me, AA is really very simple: 

- we set the allocation. I.e. 10% stocks, 90% bonds.
- we enter the investments we own, i.e. Stocks Fund, Bonds Fund, Direct Bond, 
favorite company ABC stock, etc. 
- we link the investments (by symbol) to the allocation classes above.
  Stocks Fund => stocks
  Bonds Fund => bonds
  Direct Bond => bonds
  ABC => stocks
- we get the latest prices

All that computer software needs to do (and, deep into 21st century this is the 
least I'd expect my personal finance app to do) is to calculate the current 
value of the holdings, therefore asset classes, and say:
"you have 50K in investments, out of which 30% is in stocks and 70% in bonds, 
while your allocation is 10%/90%".

> Asset Allocation is indeed simple, the problem is that no two people 
> agree on how to do it :)
> 
> Further, most AA models are USA biased, I don't think gnc needs any more 
> USA bias and any model that includes a stock allocation along the lines 
> of "domestic / foreign" is rubbish if you live outside of the USA so 
> let's not go there! [1]

OK. This is an interesting distinction. Are we talking about AA as a concept or 
a concrete AA implementation (values)? This is kinda class/instance 
relationship. I'm strictly interested in providing a tool that allows working 
with AA as a concept, and leave the actual implementation to the user. They can 
work out their allocations in any way they prefer but the tool should be 
accessible and use the portfolio data from a GC book.
Just like a text editor, it does not tell you how to write but lets you write 
some text, save it, view/edit it later, and share it with someone else.

> for a sanity check, I am certain the good people that maintain the code 
> that allows us to get prices do *not* try to maintain a complete db of 
> prices themselves.  there is, quite simply, too much information.

Nobody mentioned a complete db of prices but separating Price information from 
the rest of the book. Prices are expendable and, as you say, can be retrieved 
independently. As they are independent of a book, they can be shared across 
multiple books and/or applications. Which is where I'm coming from. And price 
information is pretty much the same for any application. It has basic 
properties of Date(/Time), Symbol, and Value.

> you haven't been looking, there are hundreds of AA implementations, 
> maybe you mean you haven't found many that agree with your 
> preconceptions ? AA is often about preconceptions.

Good advice. I see a few implementations, thanks to Python being so accessible. 
However, it seems that most of them are dealing with calculating an optimal 
allocation rather than letting the user manage it, the way ledger-cli (or MMEX 
4 Android) does.

> Heh, you just outed yourself as a bad trader :)  A "good" trader doesn't 
> care about capital gains :)

I don't really. But I have to report on it to the tax authorities every year. ;)

On a side note, I'm pretty amazed how few people are interested in AA 
considering that they are the masters of their own fortune in countries with 
private pension funds. In countries like Australia, each person is responsible 
for choosing their superannuation fund, including the asset allocation.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 12/02/2018 18:57, Alen Siljak wrote:




Sent: Monday, February 12, 2018 at 7:34 PM
From: "Wm via gnucash-devel" <gnucash-devel@gnucash.org>
To: gnucash-de...@lists.gnucash.org
Subject: Re: price.date, transaction.post_date and neutral time

On 12/02/2018 14:27, Alen Siljak wrote:

 I am currently separating the Asset Allocation logic into its own
 Python package, for direct use (cli) and potential library reuse
 between GnuCash Portfolio and an Android app (perhaps an add-on for
 MoneyManagerEx or who knows where it leads).


MoneyManagerEx is single entry and will never get approval in the double
entry community.  I like they way they do reports, but their
understanding of accounting is broken.


True but, as a maintainer of MMEX for Android app, I have already implemented 
Asset Allocation module there. The mobile app served me well for years by 
providing transactions in .qif files, which GnuCash also handles well. So, it 
remains my mobile app of choice for the moment, in combination with GnuCash.



That is interesting.  There has been quite a lot of enthusiasm for 
mobile / gnc interaction.  Have you written about this before and I 
missed it ?  If MMEX for Android is working well with gnc I think you 
should make a wiki entry and ignore my view on MMEX as an accounting app.


Aside: I am completely confused how MMEX for Android could be used for 
Asset Allocation, MMEX doesn't understand Assets and Liabilities and 
Equity!  Looking at the forums, the dev's of MMEX haven't realised that 
prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for 
Android app is moving beyond MMEX itself and may be working better with 
gnc then please let us know,



What I would like to do, is extract the AA logic from the app, implement in 
some platform-neutral way (python?) and use on desktop and mobile. Since it is 
not complex, there is no reason for GnuCash not to implement the same concept. 
After all, it simply takes user-set allocation and compares to the quantity of 
the various commodities owned, calculating their current value by using their 
current price. Hence the need to have Allocation and Price elements.


Asset Allocation is indeed simple, the problem is that no two people 
agree on how to do it :)


Further, most AA models are USA biased, I don't think gnc needs any more 
USA bias and any model that includes a stock allocation along the lines 
of "domestic / foreign" is rubbish if you live outside of the USA so 
let's not go there! [1]


The ledger-cli AA approach works for me because I say what my AA is and 
the sums just work. I can copy and paste the output into a spreadsheet 
and see a pie chart, I can make my AA as detailed or top down or bottom 
up as I like.  It is flexible not prescriptive.  As soon as you start 
coding any of that into an app like gnc you lose the flexibility and 
start telling people "do AA like this or that".  In essence you are 
saying "I'm right, you are wrong".  I disagree with that.


The problem is that AA is like Budgeting, we agree it should be done but 
not how or why or what the point is.  For that reason I ask that the gnc 
db is more accessible and that AA and Budgeting are ripped out of the 
main application.


Am I making sense yet?

I am arguing *strongly* that any personal view AA or Budget should 
*never* be included in the main gnc app.



We spoke about this before.  gnc is a bad platform for trading, end of
discussion.


I was not in any way referring to trading but to reusing the price database 
file/schema. But it seems that it would be too much trouble for such a small 
component so nevermind.


gnc is a bad place to start if you want a comprehensive price db

gnc uses the price db for valuing stuff.  it is *not* a good way of 
recording historic prices of commodities in general.  the purpose of the 
gnc price db is for *you* to know about *your* stuff rather than finding 
out about stuff you have never owned.


if you really want to know and keep the prices of everything (which is a 
dumb thing to desire) then get a broker account <-- they aren't cheap.


for a sanity check, I am certain the good people that maintain the code 
that allows us to get prices do *not* try to maintain a complete db of 
prices themselves.  there is, quite simply, too much information.



 I'm wondering what the opinion here in the project would be about such
 an idea in terms of reuse and/or tools for populating and reading the
 database.


My advice is don't go there.


I still need to read the latest available prices from somewhere. I could use 
GnuCash book, of course, but I hate to pollute it with a bunch of prices that 
don't have real use inside GnuCash anyway. Actually, I'd prefer not to download 
any prices into my GC book apart from the ones that are generated automatically 
on conversion. And even those I'd prefer to clean up from time to time.
I believe I'll d

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

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 ?


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.


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 :)


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Sébastien de Menten]

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.

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).


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)


On Feb 12, 2018 15:18, "Wm via gnucash-devel" 
wrote:

On 11/02/2018 12:33, Sébastien de Menten wrote:

> When exporting data from SQL backends, I see some inconsistencies in the
> handling of some date & datetime columns.
>
> In the prices table, when adding price via the price editor, I see in the
> date column a datetime with the UTC of the /MM/DD 00:00:00 of my local
> timezone (CET).
> For instance, for a price on 11/02/2018, I see  2018021023, which is
> the UTC value for 11/02/2018 00:00:00+01:00.
> What is the reason of having the prices.date as a datetime type (vs a
> simple date type) ?
> Shouldn't it also be stored as  20180211105900, i.e. in neutral time as the
> field transaction.post_date ?
>
> In the transactions table, the post_date is handled as a date in gnucash
> but stored also in a datetime type with the neutral time (10:59:00).
> So for a transaction on 11/02/2018, I see 20180211105900.
> What is the reason of having the transactions.post_date as a datetime type
> (vs a simple date type) ?
>
> If the reason are mostly legacy, are there some plans to change that in 3.0
> ?
>
> IIRC the discussion at the time was about whether gnc should or could be
used for trading.  the result was "no" and it was decided that the price db
should only have one entry per day (some people wanted multiple entries per
day in an attempt to use gnc for trading, that was never going to work as
gnc is a crap model for all the other stuff short term traders need, like
quick graphs, moving averages, etc).

given that, are you unhappy with the way gnc records date / price
combinations ?

-- 
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

> Sent: Monday, February 12, 2018 at 7:34 PM
> From: "Wm via gnucash-devel" <gnucash-devel@gnucash.org>
> To: gnucash-de...@lists.gnucash.org
> Subject: Re: price.date, transaction.post_date and neutral time
>
> On 12/02/2018 14:27, Alen Siljak wrote:
> > I am currently separating the Asset Allocation logic into its own
> > Python package, for direct use (cli) and potential library reuse
> > between GnuCash Portfolio and an Android app (perhaps an add-on for
> > MoneyManagerEx or who knows where it leads).
> 
> MoneyManagerEx is single entry and will never get approval in the double 
> entry community.  I like they way they do reports, but their 
> understanding of accounting is broken.

True but, as a maintainer of MMEX for Android app, I have already implemented 
Asset Allocation module there. The mobile app served me well for years by 
providing transactions in .qif files, which GnuCash also handles well. So, it 
remains my mobile app of choice for the moment, in combination with GnuCash.

What I would like to do, is extract the AA logic from the app, implement in 
some platform-neutral way (python?) and use on desktop and mobile. Since it is 
not complex, there is no reason for GnuCash not to implement the same concept. 
After all, it simply takes user-set allocation and compares to the quantity of 
the various commodities owned, calculating their current value by using their 
current price. Hence the need to have Allocation and Price elements.

> We spoke about this before.  gnc is a bad platform for trading, end of 
> discussion.

I was not in any way referring to trading but to reusing the price database 
file/schema. But it seems that it would be too much trouble for such a small 
component so nevermind.

> > I'm wondering what the opinion here in the project would be about such
> > an idea in terms of reuse and/or tools for populating and reading the
> > database.
> 
> My advice is don't go there.

I still need to read the latest available prices from somewhere. I could use 
GnuCash book, of course, but I hate to pollute it with a bunch of prices that 
don't have real use inside GnuCash anyway. Actually, I'd prefer not to download 
any prices into my GC book apart from the ones that are generated automatically 
on conversion. And even those I'd prefer to clean up from time to time.
I believe I'll do all the price-sensitive calculations outside GC by reading 
from a separate database (or another source).

> > I will definitely be creating a separate project for this, just hoping
> > someone else is interested.
> 
> There is lots of scope in other projects, I don't like people forcing 
> one to be another

Hm, that gives me a few ideas already. One thing I keep forgetting is to check 
if perhaps someone has a similar project already. Or I could simply try 
fetching and caching the latest prices for all symbols on startup. And to 
support offline calculations, I'd still need to save data to a db. Something to 
be worked-out.

Anyway, it would be nice to see Asset Allocation module in GnuCash. The current 
implementation is just two tables. But I'm not sure if it would satisfy 
everybody right now. 
The only other AA implementation I found is in ledger but I have not tested it 
properly because my exported book doesn't balance in ledger due to mismatch in 
handling capital gains transactions between GC and ledger. :(

Cheers
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 12/02/2018 14:27, Alen Siljak wrote:

This is interesting information.
I am currently separating the Asset Allocation logic into its own
Python package, for direct use (cli) and potential library reuse
between GnuCash Portfolio and an Android app (perhaps an add-on for
MoneyManagerEx or who knows where it leads).


MoneyManagerEx is single entry and will never get approval in the double 
entry community.  I like they way they do reports, but their 
understanding of accounting is broken.



In any case, it seems that Prices seems a likely candidate for
separation, as well, as that can definitely be reused by multiple
projects, contains simple data, and can get huge hence it seems better
to have it separate to the main database.


All of the main text accounting projects can get prices in near real 
time.  They deliberately don't do minute by minute.



Now, this raises an interesting question of whether GnuCash would
benefit from the same concept and perhaps reuse the price db. This
might even be invisible to an average user but someone more advanced
could take advantage. The internal GnuCash logic could remain
more-or-less the same, in getting the latest price for the day only.
I think a single table might be enough for this purpose, pretty much
what's in GnuCash now. I have not yet looked into details for this.


We spoke about this before.  gnc is a bad platform for trading, end of 
discussion.



I'm wondering what the opinion here in the project would be about such
an idea in terms of reuse and/or tools for populating and reading the
database.


My advice is don't go there.


I will definitely be creating a separate project for this, just hoping
someone else is interested.


There is lots of scope in other projects, I don't like people forcing 
one to be another




Sent: Monday, February 12, 2018 at 3:17 PM
From: "Wm via gnucash-devel" <gnucash-devel@gnucash.org>
To: gnucash-de...@lists.gnucash.org
    Subject: Re: price.date, transaction.post_date and neutral time
IIRC the discussion at the time was about whether gnc should or could
be
used for trading. the result was "no" and it was decided that the price
db should only have one entry per day (some people wanted multiple
entries per day in an attempt to use gnc for trading, that was never
going to work as gnc is a crap model for all the other stuff short term
traders need, like quick graphs, moving averages, etc).




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Alen Siljak]

   This is interesting information.
   I am currently separating the Asset Allocation logic into its own
   Python package, for direct use (cli) and potential library reuse
   between GnuCash Portfolio and an Android app (perhaps an add-on for
   MoneyManagerEx or who knows where it leads).
   In any case, it seems that Prices seems a likely candidate for
   separation, as well, as that can definitely be reused by multiple
   projects, contains simple data, and can get huge hence it seems better
   to have it separate to the main database.

   Now, this raises an interesting question of whether GnuCash would
   benefit from the same concept and perhaps reuse the price db. This
   might even be invisible to an average user but someone more advanced
   could take advantage. The internal GnuCash logic could remain
   more-or-less the same, in getting the latest price for the day only.
   I think a single table might be enough for this purpose, pretty much
   what's in GnuCash now. I have not yet looked into details for this.

   I'm wondering what the opinion here in the project would be about such
   an idea in terms of reuse and/or tools for populating and reading the
   database.
   I will definitely be creating a separate project for this, just hoping
   someone else is interested.

   Sent: Monday, February 12, 2018 at 3:17 PM
   From: "Wm via gnucash-devel" <gnucash-devel@gnucash.org>
   To: gnucash-de...@lists.gnucash.org
   Subject: Re: price.date, transaction.post_date and neutral time
   IIRC the discussion at the time was about whether gnc should or could
   be
   used for trading. the result was "no" and it was decided that the price
   db should only have one entry per day (some people wanted multiple
   entries per day in an attempt to use gnc for trading, that was never
   going to work as gnc is a crap model for all the other stuff short term
   traders need, like quick graphs, moving averages, etc).
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Wm via gnucash-devel]

On 11/02/2018 12:33, Sébastien de Menten wrote:

When exporting data from SQL backends, I see some inconsistencies in the
handling of some date & datetime columns.

In the prices table, when adding price via the price editor, I see in the
date column a datetime with the UTC of the /MM/DD 00:00:00 of my local
timezone (CET).
For instance, for a price on 11/02/2018, I see  2018021023, which is
the UTC value for 11/02/2018 00:00:00+01:00.
What is the reason of having the prices.date as a datetime type (vs a
simple date type) ?
Shouldn't it also be stored as  20180211105900, i.e. in neutral time as the
field transaction.post_date ?

In the transactions table, the post_date is handled as a date in gnucash
but stored also in a datetime type with the neutral time (10:59:00).
So for a transaction on 11/02/2018, I see 20180211105900.
What is the reason of having the transactions.post_date as a datetime type
(vs a simple date type) ?

If the reason are mostly legacy, are there some plans to change that in 3.0
?

IIRC the discussion at the time was about whether gnc should or could be 
used for trading.  the result was "no" and it was decided that the price 
db should only have one entry per day (some people wanted multiple 
entries per day in an attempt to use gnc for trading, that was never 
going to work as gnc is a crap model for all the other stuff short term 
traders need, like quick graphs, moving averages, etc).


given that, are you unhappy with the way gnc records date / price 
combinations ?


--
Wm

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[John Ralls]

The reason post_date is (as of 2.6.12) treated specially is that people expect 
to change timezones and have the displayed posted date for a transaction not 
change on them. Prices in general have a specific date-time associated with 
them, particularly if the market on which the security trades is open at the 
time of the quote. That's an absolute time anchored in the market's time zone, 
not the user's. 

Regards,
John Ralls

> On Feb 11, 2018, at 8:42 AM, Sébastien de Menten  wrote:
> 
> Yes definitely not a top priority if it works and the change is costly and 
> delicate.
> 
> Regarding prices.date not being handled in neutral time, is there some 
> difference with transactions.post_date regarding it's behavior/type or should 
> it also use neutral time?
> 
> On Feb 11, 2018 16:53, "John Ralls"  wrote:
> 
> 
> > On Feb 11, 2018, at 4:33 AM, Sébastien de Menten  
> > wrote:
> >
> > When exporting data from SQL backends, I see some inconsistencies in the
> > handling of some date & datetime columns.
> >
> > In the prices table, when adding price via the price editor, I see in the
> > date column a datetime with the UTC of the /MM/DD 00:00:00 of my local
> > timezone (CET).
> > For instance, for a price on 11/02/2018, I see  2018021023, which is
> > the UTC value for 11/02/2018 00:00:00+01:00.
> > What is the reason of having the prices.date as a datetime type (vs a
> > simple date type) ?
> > Shouldn't it also be stored as  20180211105900, i.e. in neutral time as the
> > field transaction.post_date ?
> >
> > In the transactions table, the post_date is handled as a date in gnucash
> > but stored also in a datetime type with the neutral time (10:59:00).
> > So for a transaction on 11/02/2018, I see 20180211105900.
> > What is the reason of having the transactions.post_date as a datetime type
> > (vs a simple date type) ?
> >
> > If the reason are mostly legacy, are there some plans to change that in 3.0
> > ?
> > _
> 
> 
> The short answer is it’s legacy and while there are plans to perhaps change 
> it, that didn’t happen in time for GnuCash 3.x and may not for 4.x.
> 
> They’re stored as TIMESTAMP because their internal representation is 
> effectively time_t, and the internal representation is time_t because when it 
> was written that’s what was available for time computations... in fact, until 
> C++17’s std::chrono came along it and its companion struct tm were still the 
> only standard time representations.
> 
> It’s an incredible amount of work to change the time representation. I 
> started with 64-bit time and GDateTime in GnuCash 2.6; then we decided to 
> divorce from GLib and so time that might have gone into reworking 
> calculations got spent instead on converting to a C++ time implementation, 
> which at least has the benefit of having an actual date representation 
> integrated into it (GDate and GDateTime are completely orthogonal). As you 
> might expect, calculations with post_date are pervasive throughout GnuCash 
> and changing its representation will be a lot of work. That will happen in 
> the course of C++ conversion and MVC cleanup, but like so many other things 
> there’s a lot of preparation first, and frankly there are more important 
> things to work on.
> 
> Regards,
> John Ralls
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[Sébastien de Menten]

Yes definitely not a top priority if it works and the change is costly and
delicate.

Regarding prices.date not being handled in neutral time, is there some
difference with transactions.post_date regarding it's behavior/type or
should it also use neutral time?

On Feb 11, 2018 16:53, "John Ralls"  wrote:

>
>
> > On Feb 11, 2018, at 4:33 AM, Sébastien de Menten 
> wrote:
> >
> > When exporting data from SQL backends, I see some inconsistencies in the
> > handling of some date & datetime columns.
> >
> > In the prices table, when adding price via the price editor, I see in the
> > date column a datetime with the UTC of the /MM/DD 00:00:00 of my
> local
> > timezone (CET).
> > For instance, for a price on 11/02/2018, I see  2018021023, which is
> > the UTC value for 11/02/2018 00:00:00+01:00.
> > What is the reason of having the prices.date as a datetime type (vs a
> > simple date type) ?
> > Shouldn't it also be stored as  20180211105900, i.e. in neutral time as
> the
> > field transaction.post_date ?
> >
> > In the transactions table, the post_date is handled as a date in gnucash
> > but stored also in a datetime type with the neutral time (10:59:00).
> > So for a transaction on 11/02/2018, I see 20180211105900.
> > What is the reason of having the transactions.post_date as a datetime
> type
> > (vs a simple date type) ?
> >
> > If the reason are mostly legacy, are there some plans to change that in
> 3.0
> > ?
> > _
>
>
> The short answer is it’s legacy and while there are plans to perhaps
> change it, that didn’t happen in time for GnuCash 3.x and may not for 4.x.
>
> They’re stored as TIMESTAMP because their internal representation is
> effectively time_t, and the internal representation is time_t because when
> it was written that’s what was available for time computations... in fact,
> until C++17’s std::chrono came along it and its companion struct tm were
> still the only standard time representations.
>
> It’s an incredible amount of work to change the time representation. I
> started with 64-bit time and GDateTime in GnuCash 2.6; then we decided to
> divorce from GLib and so time that might have gone into reworking
> calculations got spent instead on converting to a C++ time implementation,
> which at least has the benefit of having an actual date representation
> integrated into it (GDate and GDateTime are completely orthogonal). As you
> might expect, calculations with post_date are pervasive throughout GnuCash
> and changing its representation will be a lot of work. That will happen in
> the course of C++ conversion and MVC cleanup, but like so many other things
> there’s a lot of preparation first, and frankly there are more important
> things to work on.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: price.date, transaction.post_date and neutral time

[John Ralls]

> On Feb 11, 2018, at 4:33 AM, Sébastien de Menten  wrote:
> 
> When exporting data from SQL backends, I see some inconsistencies in the
> handling of some date & datetime columns.
> 
> In the prices table, when adding price via the price editor, I see in the
> date column a datetime with the UTC of the /MM/DD 00:00:00 of my local
> timezone (CET).
> For instance, for a price on 11/02/2018, I see  2018021023, which is
> the UTC value for 11/02/2018 00:00:00+01:00.
> What is the reason of having the prices.date as a datetime type (vs a
> simple date type) ?
> Shouldn't it also be stored as  20180211105900, i.e. in neutral time as the
> field transaction.post_date ?
> 
> In the transactions table, the post_date is handled as a date in gnucash
> but stored also in a datetime type with the neutral time (10:59:00).
> So for a transaction on 11/02/2018, I see 20180211105900.
> What is the reason of having the transactions.post_date as a datetime type
> (vs a simple date type) ?
> 
> If the reason are mostly legacy, are there some plans to change that in 3.0
> ?
> _


The short answer is it’s legacy and while there are plans to perhaps change it, 
that didn’t happen in time for GnuCash 3.x and may not for 4.x.

They’re stored as TIMESTAMP because their internal representation is 
effectively time_t, and the internal representation is time_t because when it 
was written that’s what was available for time computations... in fact, until 
C++17’s std::chrono came along it and its companion struct tm were still the 
only standard time representations.

It’s an incredible amount of work to change the time representation. I started 
with 64-bit time and GDateTime in GnuCash 2.6; then we decided to divorce from 
GLib and so time that might have gone into reworking calculations got spent 
instead on converting to a C++ time implementation, which at least has the 
benefit of having an actual date representation integrated into it (GDate and 
GDateTime are completely orthogonal). As you might expect, calculations with 
post_date are pervasive throughout GnuCash and changing its representation will 
be a lot of work. That will happen in the course of C++ conversion and MVC 
cleanup, but like so many other things there’s a lot of preparation first, and 
frankly there are more important things to work on.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

price.date, transaction.post_date and neutral time

[Sébastien de Menten]

When exporting data from SQL backends, I see some inconsistencies in the
handling of some date & datetime columns.

In the prices table, when adding price via the price editor, I see in the
date column a datetime with the UTC of the /MM/DD 00:00:00 of my local
timezone (CET).
For instance, for a price on 11/02/2018, I see  2018021023, which is
the UTC value for 11/02/2018 00:00:00+01:00.
What is the reason of having the prices.date as a datetime type (vs a
simple date type) ?
Shouldn't it also be stored as  20180211105900, i.e. in neutral time as the
field transaction.post_date ?

In the transactions table, the post_date is handled as a date in gnucash
but stored also in a datetime type with the neutral time (10:59:00).
So for a transaction on 11/02/2018, I see 20180211105900.
What is the reason of having the transactions.post_date as a datetime type
(vs a simple date type) ?

If the reason are mostly legacy, are there some plans to change that in 3.0
?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel