Posting time bug fix proposal (simplified)

Charles Day cedayiv at
Tue Aug 19 17:09:04 EDT 2008

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

> Hi,
> Mike or Penny Novack <stepbystepfarm at> 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:    PP-ASEL-IA     N1NWH
>       warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list