John,
> ---------- Forwarded message ---------- > From: John Ralls <jra...@ceridwen.us> > To: Christian Stimming <christ...@cstimming.de> > Cc: gnucash-devel@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 <christ...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
