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 comm
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 alloc
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 => st
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 calcu
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 jus
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
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 o
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
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
>> d
> Sent: Tuesday, February 13, 2018 at 8:13 AM
> From: "Wm via gnucash-devel"
> 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
> mobi
On 12/02/2018 18:57, Alen Siljak wrote:
Sent: Monday, February 12, 2018 at 7:34 PM
From: "Wm via gnucash-devel"
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 sepa
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
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.
> Sent: Monday, February 12, 2018 at 7:34 PM
> From: "Wm via gnucash-devel"
> 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 t
e 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"
To: gnucash-de...@lists.gnucash.org
Subject: Re: price.date, transaction.post
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"
To: gnucash-de...@lists.gnucash.org
Subject: Re: price.date, transaction.post_date and
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
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
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"
> 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
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
21 matches
Mail list logo
