Transaction Entry Dates

[John Ralls]

On Jul 21, 2014, at 4:14 PM, Lance Edgar <lance at edbob.org> wrote:

> 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.

A bit convoluted, and there's a potential performance hit using slot data instead of the main table. But consider the alternative of the "editable time" proposal I made yesterday, where the default time unless edited is 1100Z, and the table date-time always supplies the date:

Scenario 1: No problems except in the westernmost timezone, Z-12, when recording transactions between 2300 and 2359 standard time. Daylight time is Z-11, so that works all the time. In all other TZs the date is correct. 

Scenario 2: Same as scenario 1.

Scenario 3: This has the potential of causing problems for transactions with times in the hour before midnight standard time or the hour after midnight daylight time because there's can't be any normalization without losing the time info. However this can be resolved by checking whether DST is in effect on the date of the transaction.

Scenario 4: Can only be made to work by either consulting the date in the slot or by creating a TZ option for the file and recording all times as being in that TZ. Using the slot date is potentially confusing in the multi-user, multi-TZ scenario because a user in e.g. China could enter a transaction for a particular local date and time, and another user in e.g. the US might enter one for what is in fact an hour later, but it will be the day before in the local TZ.

Note as well that setting a default TZ for the book can overcome the Z-12 problem as well in scenarios 1 and 2.

I'm still not convinced that there's a good accounting use case for recording times. As David Carlson pointed out yesterday, the exercise is not about making your books match your bank's line-by-line, it's about making sure that all of the transactions are reflected in both sets of books.  It's quite normal to see "float" between two sets of books.

Regards,
John Ralls