Dear John, yes, your proposal sounds like a good way to go. Thanks for explaining this and thanks for all the good work!
Regards, Christian Am 20. Juni 2016 00:15:22 MESZ, schrieb John Ralls <jra...@ceridwen.us>: > >> 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 -- Sent from mobile. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
