Transaction Posted Time

[Christian Stimming (mobil)]

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 <jralls at ceridwen.us>:
>
>> 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

--
Sent from mobile.