Posting time bug fix proposal (simplified)

[Charles Day]

On Tue, Aug 19, 2008 at 10:16 AM, Derek Atkins <warlord at mit.edu> wrote:

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

Actually it's moving west that causes the date to change. Moving east is OK
unless you jump forward 24 hours (like Samoa to Tonga). I know, picky,
picky.  -Charles

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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>