Transaction Entry Dates

[John Ralls]

On Jul 20, 2014, at 6:10 PM, David Carlson <david.carlson.417 at gmail.com> wrote:

> On 7/20/2014 9:58 AM, John Ralls wrote:
>> On Jul 20, 2014, at 1:26 PM, David Carlson <david.carlson.417 at gmail.com> wrote:
>> 
>>> On 7/20/2014 5: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
>>>> 
>>> My bank posts the minute and second (Local time) when I use a computer
>>> to transfer funds between accounts, but I think that it is only an aid
>>> to uniquely identify transactions if there happens to be similar ones in
>>> the same account. That, in itself, is a valid reason to keep the time in
>>> the transaction record, but I think that it might be better in GnuCash
>>> to also add the time zone of the user who made the entry to the
>>> transaction (including Daylight time when applicable). Then the date
>>> could be shown as local date (of the user that posted the transaction)
>>> to solve the date display issue.
>> Sorry, how does saving a local date with TZ differ from converting to Z if one then converts to the current local TZ when presenting the record?
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> 
> I meant that GnuCash should display the same date that the user who
> entered each transaction saw at the time that he made the entry.  This
> is not necessarily the current users time zone.  If the local date with
> TZ is already saved, then just compare that to the current user's time
> zone and adjust if required to to display the date that the original
> user saw.

That won't work if there are two users in different time zones, perhaps Tokyo and San Francisco, where there's an 18-hour difference; when the SF user is entering a transaction it's often already tomorrow in Tokyo. Converting the time to Z avoids that.

Regards,
John Ralls