Transaction Entry Dates

[Lance Edgar]

On 07/21/2014 03:00 AM, John Ralls wrote:
>
> On Jul 21, 2014, at 6:18 AM, Lance Edgar <lance at edbob.org> wrote:
>
>> On 07/20/2014 08:15 PM, Lance Edgar wrote:
>>> 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.
>>
>> Hm, so I just compiled GnuCash from git HEAD and did the same test (figured it wasn't safe to assume much about what "current" code did given that I run 2.4 normally) and I see there already is such a "date" field added for new transactions, a la:
>>
>>   <trn:date-posted>
>>     <ts:date>2014-07-20 00:00:00 -0700</ts:date>
>>   </trn:date-posted>
>>   <trn:slots>
>>     <slot>
>>       <slot:key>date-posted</slot:key>
>>       <slot:value type="gdate">
>>         <gdate>2014-07-20</gdate>
>>       </slot:value>
>>     </slot>
>>   </trn:slots>
>>
>> So I'm not sure what (if anything) that changes, e.g. not sure what the purpose of that field is currently.  Still curious if such a date field could be used to solve the TZ display problem, and yet still allow the full date-time-TZ value stored for those who needed time data (with the understanding that the two would be used differently).
>
> It's there, but it's used only in a couple of special cases: When assigning a payment date to an invoice, and for managing the date in the partially-implemented manual reordering of transactions in the register.
>
> So your proposal is to use the slot date unless the user has enabled display of times, or in that case to use the full timestamp?
>
> That's doable.

Yes that's the basic idea.  I actually had thought the slot date would 
be used in *all* cases to indicate the "true" date for the transaction, 
even if time display was enabled.  That gets tricky when multiple TZ's 
are an issue though.  Here are some basic scenarios:

1. User has not enabled time display, and is concerned only with a 
single time zone.  The date they enter for a new transaction is 
"converted" to midnight as of the local time zone, as has always been 
the case.  In addition, the date portion of this value is stored 
separately (in slot).  The date shown in the register is always the slot 
date.  (Even though they're only "concerned" with one TZ, should they 
happen to travel etc. they will not be surprised by dates jumping around.)

2. User has not enabled time display, but *is* concerned with multiple 
time zones.  This would work the same as the previous, except I suppose 
it would be up to the user to establish what the "official" time zone 
might be for their book(s).  I'm not even sure how much that would 
matter if they're really only thinking in terms of dates and aren't 
needing "time" granularity on their transactions.  As long as they enter 
the correct date, it will stick even if some transactions have different 
time zones in the timestamp field.

3. User *has* enabled time display, but is *not* concerned with multiple 
time zones.  If the user really can assume a single time zone in all 
cases (can this be "forced" per book, independent of what the OS would 
declare?), then everything above still holds, except that the time 
portion may not be midnight since the user can edit it.  But if the TZ 
is known to be stable, the date could *still* be displayed using the 
slot date and the date/time pair would appear accurate even though 
technically they come from different fields.

4. User *has* enabled time display and *is* concerned with multiple time 
zones.  Starts to get pretty tricky here.  However I think if a user 
knows they're concerned with multiple time zones, they will need to know 
what that means for the interaction of dates and times.  My idea was to 
*still* show the slot date for the txn date even though the time portion 
has the potential to "belong" to a different date depending on the TZ. 
In this case however I think the time field would need "more" in the UI, 
i.e. it would need the full date-time-TZ of its own, in addition to the 
separate date field.  I'm quite confident that will need some hashing 
out :) but again the point here is that the user *knows* they need to be 
concerned with TZ issues, so this would be a way to expose them. 
(Presumably the "simpler" UI from previous scenario could still be used 
even with multi-TZ *as long as* certain constraints held, e.g. the time 
zones weren't that far apart, and txn times kept to "normal business 
hours" and avoided anything near midnight.)

Obviously if the user has enabled display of times, then that would 
create more questions.  That last scenario in particular seems a thorny 
one.  But just wanted to clarify that I *did* still mean for the slot 
date to show in all cases, and for time display to be a sort of separate 
concern.  How the time related to the date would be "transparent" in the 
case of single TZ, and would require the user to understand (and be able 
to see) the relationship in case of multi TZ.

Lance