Patch : editing "Posted" time of transactions.

Michael Ferrara mferrara1 at
Thu May 28 14:02:33 EDT 2015

I see how noting transaction times down to the fraction of a second could
be useful for quantitative analysis of a stock market. For instance, I know
a guy working on relativistic trading... That is, markets and computers are
getting so fast that the SEC has to factor in nano-seconds, GPS, and
Einstein in making decisions.

OTOH, for daily errands around town, I simply record the time printed on my
receipt, which is accurate to the minute. The IRS discounts nano-seconds
like it drops cents.

Populate the NUMBER field with the HH:MM or perhaps HH:MM:SS of the
transaction and viola, the day's ledger is chronologically sorted.

I am happy nevertheless to see lower level development on this matter of
the timestamp. Thanks, Daniel.

On May 28, 2015 8:17 AM, "John Ralls" <jralls at> wrote:

> > On May 28, 2015, at 6:37 AM, gLETTERyYuMEANSj LETTERyOt <
> gletteryyumeansjletteryot at> wrote:
> >
> > Dear developers,
> >
> > For my work I had to patch gnucash-2.6.5 so that time of transactions are
> > displayed and editable, and so that new transactions are correctly
> timestamped.
> >
> > I plan to release the resulting patches. What licence should I ask my
> boss to
> > let you use these patches ?
> >
> > If you want to test them, they are attached to this mail.
> >
> > They may not suit you:
> >
> > - The default timezone used for display *should* be specified in the
> >  environment variable TZ in the form "[^-+]*+HHMM$", HH and MM being
> hours and
> >  minutes to add to UTC times to get the local time (including the
> possible
> >  daylight saving time correction).
> >
> > - These patches cannot be disabled by configuration (a patch to
> > is lacking).
> >
> > - A lot of debugging messages related to this patch are written to
> standard
> >  output.
> >
> > Other details, from the ChangeLog:
> >
> > Patch to show the timezone and time at left of date (enlarge date
> > column of the ledger to see that). The time +0000 00:00:00 is
> > implicit when loading gnucash files created without this patch. The
> > time +0000 12:00:00 is implicit when the user do not specify a time.
> > The entered date will override a Posted time of +0000 12:00:00, if
> > entered date is within 13h of posted date. This is useful to
> > timestamp new transactions.
> >
> Daniel,
> Please don’t submit patches to the mailing list. Open a bug in
> or fork our repo on Github, create a branch with your
> patch, and make a pull request. Patches should be written against HEAD in
> the branch you’re working on — which should be master for a feature
> request, especially one that changes the database or the way it’s
> interpreted. We wouldn’t make a change like that in a stable series.
> All contributions to GnuCash must be licensed under the GNU General Public
> License, version 2 or later.
> What’s the reason for using an environment variable for determining
> timezone? TZ seems not commonly used and it would be trivially easy to add
> a function to get the UTC offset in gnc-date.cpp.
> Diagnostic messages should be logged using the appropriate macro from
> src/libqof/qof/qoflog.cpp: PINFO or PDEBUG are most appropriate for
> debugging messages.
> Entry date handling has long been a matter of controversy in GnuCash, and
> switching the nominal time to 11:00 UTC from 00:00 UTC is the simplest
> option to resolve most of it. 11:00 instead of 12:00 because New Zealand’s
> summer time offset is +13 hours and the total population of the -12
> timezone is only a few thousand people. That change is already planned for
> GnuCash 2.8 unless we decide to go in either of the directions Geert
> mentioned.
> My understanding is that it’s unusual for accountants to care much about
> exact transaction times, so I’m curious about your business case for
> requiring it. Please elaborate on that.
> Regards,
> John Ralls
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list