Transaction Entry Dates

[Lance Edgar]

On 07/20/2014 01:55 PM, John Ralls wrote:
>
> On Jul 20, 2014, at 6:11 PM, Lance Edgar <lance at edbob.org> wrote:
>
>> On 07/20/2014 03:30 AM, John Ralls wrote:
>>> It has been a long-standing and often discussed problem that transaction entry dates can change with time zone, and https://bugzilla.gnome.org/show_bug.cgi?id=137017 has many useful comments on the subject. But today I discovered https://bugzilla.gnome.org/show_bug.cgi?id=89439 with an alternative view, that Date Entered should be Time Entered, and that there should be an optional column in the register to show the time. That suggests an alternative solution to the problem while adding a sorting option for transactions.
>>>
>>> I've created two "suggestions" on UserVoice. Please vote for the one you prefer:
>>>
>>> https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/6194177-add-an-optional-entry-time-field-to-the
>>> https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/6194125-fix-the-moving-entry-date-problem-by-getting-rid-o
>>>
>>> Regards,
>>> John Ralls
>>
>> These issues have not affected me personally (yet), although I see why it could be quite frustrating for those it does.  I've just read over the bug reports and the new suggestions.  My initial thought is, why must we choose between these two approaches versus combining them?  Esp. given the current UserVoice vote of 3-4; looks like you'd be leaving half the users (who prefer either approach) unsatisfied.
>>
>> In some cases it seems useful to have the actual *time* (with TZ/offset) recorded as an attribute of when a txn truly occurred, e.g. because that data is available and relevant.  That seems obvious enough from a user's perspective I think.  But in many (presumably most) cases the date is all that actually matters. Since the "problem" appears to be, "how to store and display a single data value which provides both needs", to me it begs the question, why are we not storing and displaying *two* distinct values, each of which is designed to meet a distinct need?
>>
>> This seems to have been more or less suggested already by Peter Selinger:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=137017#c28
>>
>> I have never even looked at the code, so couldn't estimate the difficulty of the effort, but adding a distinct "date" attribute in addition to whatever "time" is currently provided seems hopefully a straightforward thing?    Then the "time" enhancements (i.e. exposing in the UI etc.) could be added as a second step.
>>
>> Hopefully I haven't just repeated one half of a conversation which has been had 5 times already... ;)
>
> Continuing to use a time field while optionally exposing the time for input for users who want that is the more flexible choice, but there is no way to set a time that will produce the same date in all TZs. Setting a date only with no time and therefore no timezone correction ensures that the date is the same in all TZs but doesn't allow for recording the time for those who want it. Time as a separate field independent of date is meaningless when one must consider TZ, so that's not an option.

I understand your points but the last one makes me think I wasn't clear 
in my suggestion?  When I mentioned "time" above I really did mean a 
proper date+time+TZ value (as is used currently), so e.g. implementation 
would look something like:

When user enters a new transaction, along with it are stored:

* full timestamp with TZ / offset
* date portion of this timestamp local to current TZ

My understanding based on reading the bug reports etc. is that currently 
the first bullet above is what is happening now, except the "wall time" 
is set to midnight.  I just tested this also (on Linux with GnuCash 
2.4.10) and since I'm in California my new transaction got:

   <trn:date-posted>
     <ts:date>2014-07-20 00:00:00 -0700</ts:date>
   </trn:date-posted>

So as Peter Selinger has suggested previously, I'm suggesting keeping 
that and adding a second field which captures the date portion only.  He 
chose "calendar-date" for the name, and I don't have a reason to change 
that, so e.g. my transaction would have looked like:

   <trn:date-posted>
     <ts:date>2014-07-20 00:00:00 -0700</ts:date>
     <ts:calendar-date>2014-07-20</ts:calendar-date>
   </trn:date-posted>

Then if I decide to globe-trot, my transaction now has an 
"authoritative" and "sticky" date value to be displayed regardless of 
time zone issues.  And more exposure could be given to the actual time 
value (i.e. the field named "date" above) for those who needed it.

There are still potential issues and places where user preferences would 
need to come into play etc., but all that wouldn't matter if the above 
approach still isn't fundamentally viable or doesn't actually solve the 
problem(s).  But I wanted to give it one more shot in case my first 
explanation didn't do the idea justice.

Lance