Transaction Entry Dates

Lance Edgar lance at edbob.org
Mon Jul 21 18:34:13 EDT 2014


On 07/21/2014 09:05 AM, John Ralls wrote:
>
> On Jul 21, 2014, at 4:14 PM, Lance Edgar <lance at edbob.org> wrote:
>>
>> 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 busines
 s
 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.

My original thought would have been to include the date in the main 
table.  Nonetheless I agree there is some convolution to it.  My goal 
was to offer a way which avoided "retaining" any of the existing bugs, 
e.g. for Z-12 folks.  But:

A) I can't say with total certainty that my proposal does that.

B) I also can't say that your proposal does *not* do it.

C) The point about not having a good accounting use case for recording 
times to begin with I hadn't really considered, but may be an important one.

D) I'm not the one who will be writing this code and don't expect even 
to be negatively affected by any TZ bugs, nor will I have the need to 
enter times, personally.

So given these, I don't think I should push any further on this.  I 
mostly wanted to be sure I had made the idea clear, so as long as I've 
done that then I'll leave the rest to fate. ;)

Lance


More information about the gnucash-user mailing list