> 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
