Transfers & Payments appear out of order

[John Ralls]

> On May 5, 2017, at 8:29 PM, Adrien Monteleone <adrien.monteleone at gmail.com> wrote:
> 
> 
>> ------------------------------
>> 
>> Message: 8
>> Date: Fri, 5 May 2017 15:39:35 -0500
>> From: David Carlson <david.carlson.417 at gmail.com>
>> To: Adrien Monteleone <adrien.monteleone at gmail.com>
>> Cc: "gnucash-user at gnucash.org" <gnucash-user at gnucash.org>
>> Subject: Re: Transfers & Payments appear out of order
>> Message-ID:
>> 	<CADYgSbn0muWOu2TZxPvigP9gcE5_OtmD3pNsM0fH3F1wVRri4Q at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Adrien,
>> 
>> It appears that we are still not quite on the same page in our
>> interpretation of the issue.  Are you saying that in a given account the
>> payment and transfer button transactions sort differently than transactions
>> created by other methods?  If so, that may be a bug.  Or not.  A developer
>> may know.
> 
> Yes, that’s precisely what I’m saying.
> 
> Entering a transaction with say a debit to cash and a credit to savings sorts as expected. Using the Transfer button to accomplish this does not. That method will always yield a transaction that sorts to the beginning of the day of the transaction and it will not respect the NUM field to change that sort order.
>> 
>> I am a long-time user, but not a user of business features.
>> 
>> In general, GnuCash does not claim to manage intra-day balances.  It
>> essentially claims to balance at the end of the day.  IMO, If you actually
>> have a need to have that level of granularity you may need to look
>> elsewhere.
>> 
>> David C
> 
> If I can’t get that granularity so be it, but I do find it odd that using that button or the Process Payment feature creates transactions that not only do not sort using the same method as manually entered transactions, but also do not honor the NUM field for custom sorting.

I had a flash of inspiration from this and checked the code: The problem is that the transfer dialog sets the date timestamp to the start of the day rather than the neutral time.  
I'll get that fixed for the next release, but in the meantime there's a simple workaround: Edit the date in the register, which should re-store it at neutral time, after which it should behave properly.

Regards,
John Ralls