Re: price.date, transaction.post_date and neutral time
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
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
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
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
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
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
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
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
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
> 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
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
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
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
> 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
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
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
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
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 Mentenwrote: > > 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
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
> On Feb 11, 2018, at 4:33 AM, Sébastien de Mentenwrote: > > 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
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