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 <sdemen...@gmail.com> 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" <jra...@ceridwen.us> wrote:
> 
> 
> > On Feb 11, 2018, at 4:33 AM, Sébastien de Menten <sdemen...@gmail.com> 
> > 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 YYYY/MM/DD 00:00:00 of my local
> > timezone (CET).
> > For instance, for a price on 11/02/2018, I see  20180210230000, 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

Reply via email to