Patch : editing "Posted" time of transactions.

[John Ralls]

> On May 28, 2015, at 10:26 AM, gLETTERyYuMEANSj LETTERyOt <gletteryyumeansjletteryot at gmail.com> wrote:
> 
>> Daniel,
>> 
>> Please don't submit patches to the mailing list. Open a bug in
>> Bugzilla.gnome.org or fork our repo on Github, create a branch with your
>> patch, and make a pull request.
> 
> I'll choose the buzgilla bug.  I'll then ask my boss if I can take time for a
> github account (would be my first time), hoping he is ok with that.
> 
>> 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.
> 
> The database is not changed, but for the posted field, which now uses wanted
> times in +0000 timezone instead of "00:00:00”.

But from your first message:
> 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.

That changes the way the database is interpreted, so it disqualifies this patch from going into stable.

> 
>> All contributions to GnuCash must be licensed under the GNU General Public
>> License, version 2 or later.
> 
> I'll ask my boss about that too.
> 
>>                               it would be trivially easy to add a
>> function to get the UTC offset in gnc-date.cpp.
> 
> I unfortunately failed doing this "triviality".
> 
> I tried g_date_time_get_utc_offset (g_date_time_new_from_unix_local(/*...*/))
> and g_date_time_format (gnc_g_date_time_new_from_timespec_local (/*...*/),
> "%Z") but none of them worked (see exact details in the patch to ChangeLog) on
> my particular setup (gnucash-2.6.5 compiled for android 4.1.1).


gnc_time(NULL) - gnc_timeutc(NULL).

> 
>> Diagnostic messages should be logged using the appropriate macro from
>> src/libqof/qof/qoflog.cpp: PINFO or PDEBUG are most appropriate for
>> debugging messages.
> 
> I had a few problems:
> 
> (1) PDEBUG was not output (nor in gnucash.trace neither on
> stderr/stdout) by gnucash --extra --debug --debug --debug --debug
> --debug --debug --debug --debug --debug --debug --debug --extra
> --extra --extra --extra --extra --extra --extra --extra --extra
> --extra --extra filename.gnucash

Multiple invocations of --debug and --extra have no effect, but neither of them turn on debug logging. They turn on info logging for selected domains.

To get debug logging in qof use --log qof=debug.

> 
> (2) PINFO even prevented some files to compile
> (src/libqof/qof/gnc-date.c maybe).

A PINFO call would only prevent compilation if you called it the wrong way, and only where you called it.

> 
> So I switched to printf without looking back again at (1) or (2).
> 
>> 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
> 
> I choose 1200Z over 1100Z because this seemed a less surprising default to you,
> the gnucash developers, but it is easy to switch my patch to 1100Z. I was not
> aware of all the posts that Geert pointed to me. I was only aware of the
> strings "date_option_show_time" and "GNC_DATE_EDIT_SHOW_TIME" found in the
> sources, but these strings lead me nowhere. So I looked up "%a" in the sources,
> because abbreviated weekday name were shown in an interesting place of the
> interface. Then I followed function calls, and made the patch I just sent you.
> 
>> My understanding is that it's unusual for accountants to care much about
>> exact transaction times,
> 
> Gnucash for Android allows this, but uses a different file format and
> was slower.
> 
> Some accounts just cannot get negative, even for a minute. Think for example of
> cash.

If you enter the transactions in the correct order then they won’t, absent entries in the Num field. If you don’t, no big deal, so long as everything balances out at the end of the day.

> 
>>                         so I'm curious about your business case for
>> requiring it. Please elaborate on that.
> 
> I warn you, this might deceive a lot of gnucash developers.
> 
> I use the unit XAG, short of grams, to account all transfers between chemical
> solutions. Each second, slow reactions are possibly advancing.
> 
> The gnucash-2.6.5 interface is nice (full of details) on an Android tablet
> (with bVNC and Xvnc) to enter all transfers in real time near a colleague doing
> them.
> 
> I also had to log the characters typed in Deposit or Withdraw fields in the
> memo field, to allow for forensics. I failed this and was told to work on other
> things.
> 
> I also had to make possible for a transaction to have a different date for each
> split. I also failed this.


I think you mean “mislead” or perhaps “confuse” rather than “deceive”. 

That’s an interesting use of the program, but I’m afraid it’s not really one that 
A clarifications as well: You’re running a VNC client on the Android tablet, but GnuCash is running on a different computer on one of the supported operating systems. VNC just lets you see and interact with that other computer’s GUI from the tablet.