gnucash-devel Digest, Vol 159, Issue 12

[Alex Aycinena]

John,


> ---------- Forwarded message ----------
> From: John Ralls <jralls at ceridwen.us>
> To: Christian Stimming <christian at cstimming.de>
> Cc: gnucash-devel at gnucash.org
> Date: Sun, 19 Jun 2016 15:15:22 -0700
> Subject: Re: Transaction Posted Time
>
> > On Jun 19, 2016, at 1:07 PM, Christian Stimming <christian at cstimming.de>
> wrote:
> >
> > Am Sonntag, 19. Juni 2016, 11:31:39 schrieb John Ralls:
> >> Bug 767824[1] has me thinking about this again. As I think everyone
> knows I
> >> want to change it from midnight local to 11:00AM UTC for the next
> version,
> >> but since fixing this bug also requires a scrub function at file read
> time
> >> to correct the (probably few) files with borked timestamps I'm thinking
> of
> >> doing it now.
> >
> > Thanks for the info. In fact I didn't recognize your idea to change the
> posted
> > date's time-of-day.
> >
> > Did you review bug https://bugzilla.gnome.org/show_bug.cgi?id=137017
> for this?
> > My take is that the "posted date" should be changed into a data type that
> > doesn't have any time-of-day anymore. As long as this is not the case,
> we will
> > IMHO always run into troubles.
> >
> > At the time bug 137017 was discussed in 2010, I decided to add the
> additional
> > KVP slot for posted date with data type GDate. Hence, since 2010 every
> > transaction has the regular posted-date timestamp (date plus
> time-of-day) plus
> > additionally a KVP slot with the posted-date (date only), where the kvp
> slot's
> > value will for sure contain the date value that was entered by the user,
> > regardless of the time zone the program was in at the time of entering.
> >
> > When you have to think about a scrub function, this additional data field
> > might become handy.
> >
> > However, some cases where the posted-date's time-of-day is chosen
> differently
> > are known:
> > - imported transactions that contained a time-of-day will have that time
> > written in here, such as those transactions that came from an OFX file
> that
> > was created by gnucash-on-android.
> > - book closing transactions contain some other time-of-day here
> > - other cases might exist, too.
> >
> > Hence, unfortunately there are still multiple use cases of the
> time-of-day
> > part of the posted-date. Any scrub functions that tries to map this
> time-of-
> > day to another one, or also a final scrub function that tries to map
> this to a
> > fixed day-only data type, will have to take all those special cases into
> > account. Unfortunately.
> >
> > Again, I would suggest to switch the posted-date data type to a date-only
> > (without time) as soon as possible, as discussed in bug 137017 and
> various
> > discussions throughout the years.
>
> Christian,
>
> You and I both agree that a date-only posted date field is the best
> solution, but we've always gotten substantial push-back from users so we've
> never changed it. Even the ability to edit the time, mentioned in comment
> 28, comes up from time to time. So if we set that aside for now, what do
> you think of using 11:00AM UTC instead of 00:00 Local, in particular
> changing in the middle of a release series?
>
> Using the transaction date slot for the scrub is an excellent idea, thanks
> for suggesting it, and thanks as well for reminding me that not all
> transactions have the timestamp adjusted to midnight local.
>
> Regards,
> John Ralls
>
> I agree with both you and Christian that date-only is the right solution.
I also don't see any realistic use case for ever displaying or making the
time editable. But there is that back-ward compatibility issue. So your
solution seems like a sensible compromise step for the current series. For
the next major series I think we should dump the time and treat it like
other new features (i.e., older releases won't load the file if it has been
written by a later release and the user gets an explanation).

Regards,

Alex