Posting time bug fix proposal (simplified)

[Derek Atkins]

Hi,

Mike or Penny Novack <stepbystepfarm at mtdata.com> writes:

> Please understand that this whole problem about "time" has me very confused.
>
> I do not understand WHAT time is under discussion. I do not understand
> the ("business") meaning of "posting time" as never in accounting have
> I come across the time at which the bookkeeper posts a transaction to
> be of the least accounting meaning. Since AFAIK that is a random time,
> I do not understand how whatever Gnucash might or might be doing with
> the time could possibly be "in error".
>
> If the time of day at which the bookkeeper enters a transaction is
> being used in some way, shape, or form as being related to the "time
> of day of the transaction" that is simply wrong in the business sense
> as there is no such relationship.

Let me try to summarize the problem.  The visible bug is that
when you set the post date of a transaction and then reset your
local timezone it's possible that all your dates will shift
a day earlier or later depending on how you adjust your local
timezone.     Obviously this is a problem -- once you set a date
it shouldn't change even if you change your local timezone, right?

So that's the visible bug that we're discussing.  Everything else is
part of the underlying implementation.

GnuCash doesn't store a "date" -- it stores an ISO-8861 timestamp.
Actually, each transaction has TWO timestamps, one is the user-visible
"post date", the other is an invisible "date entered".  The latter
is the current clock time when you create the transaction.  It's only
used for sorting and internal auditing.  The user never sees this value.
It's the former datum that is problematic, the 'post date'.

When you enter a date stamp in the UI, GnuCash chooses midnight
on that day as the timestamp to represent the day.  This works
just fine provided you never change timezones.  In fact it works fine
even if you DO change timezones provided you only move west.  If you
ever move east then you're in trouble.

We don't want to change the data file format, which means we need to
continue to choose and store a timestamp as part of the "post date",
even if the timestamp itself is (currently) arbitrary.  (as an aside,
I say "currently" because there was a proposal to allow ToD entry for
the "post date" because some users want to control when during the day
a transaction took place.)

As we have a time entry in the date stamp in the data file and cannot
change that, the underlying question is, how do we "save" that timezone
information when we read/write the file so that it's agnostic about
the local timezone.  And how do we do this in a backwards-compatible
way.

I hope this explains the problem sufficiently for you.

Thanks,

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available