Transaction Entry Dates

[John Ralls]

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.

Regards,
John Ralls