Transaction Entry Dates

[John Ralls]

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.

Regards,
John Ralls