Created attachment 372893 [details] Date/Time options in GnuCash Preferences OVERVIEW The Find Transaction pane offers 6 options for the Date Posted Search Criterion, which are as follows: 1. is before 2. is before or on 3. is on 4. is not on 5. is after 6. is on or after Options 1 and 6 return matching results as expected. Options 2 through 5 fail to return existing records that match the criteria (These are marked with an asterisk below. This is a very pesky bug, as the user has to remember which option work as expected and which don’t in order to adjust options or increment or decrement dates to yield the expected results. STEPS TO REPRODUCE preliminary steps: 1. Click “New File” and create a test database. 2. Open a register, say a bank account, and there, create 2 transactions—Transaction 1, Transaction 2, Transaction 3—dating them to 2018-01-01, 2018-01-02, and 2018-01-03, respectively. 3. Either from the main window or the register, click “Find...” steps to reproduce the bug: For each of the six options, do a search using the date of Transaction 2, 2018-01-02. Whether tapping return (enter) or clicking “Find”, the issue will occur. ACTUAL RESULTS Option 1: Transaction 1 returned. *Option 2: Transactions 1 and 2 returned. *Option 3: Transaction 2 returned. *Option 4: Transactions 1 and 3 returned. *Option 5: Transactions 3 returned. Option 6: Transactions 2 and 3 returned. * erroneous EXPECTED RESULTS Option 1: Transaction 1 returned. Option 2: Transaction 1 returned. Option 3: No transaction returned. Option 4: Transactions 1, 2, and 3 returned. Option 5: Transactions 2 and 3 returned. Option 6: Transactions 2 and 3 returned. BUILD DATE AND HARDWARE Version: 3.2 Build ID: 3.2+ (2018-06-24) ADDITIONAL BUILDS AND PLATFORM Version: 3.1 Build ID: 3.0-118-gd2ef5fd0f+ (2018-04-28) … on macOS 10.12.5 “Sierra” ADDITIONAL INFORMATION If relevant, Date/Time options in GnuCash Preferences are attached for reference. Bug 106444 is not related. Bug 785149 may be related; however, the details of the report don’t align exactly with this report and is less comprehensive than this one, in terms of the option case tested and described.
ISTM it's your expectations that are wrong. You have three transactions dated (A) 1 January 2018 (2018-01-01),(B) 2 January 2018 (2018-01-02) and (C) 3 January 2018 (2018-01-03). You are searching relative to 2 January 2018: Case 1: "is before" 2 January 2018, should return (A), and does. Case 2: "is before or on" 2 January 2018, should return (A) and (B), and does. (A) is before 2 January 2018 and transaction B is on 2 January 2018, so both match the filter. Case 3: "is on" 2 January 2018, should return (B), and does. Transaction (B) is on 2 January 2018 and so matches the filter. Case 4: "is not on" 2 January 2018, should return (A) and (C), and does. Transaction (A) is before (not on) 2 January 2018 and transaction (C) is after (not on) 2 January 2018. Transaction (B) is on 2 January 2018 and therefor doesn't match the filter. Case 5: "is after" 2 January 2018, should return (C), and does. Transaction (C) is after 2 January 2018. Transaction (B) is not and so does not match the filter. Case 6: "is on or after" 2 January 2018, should return (B) and (C), and does. The results you report are consistent with that, so how are they wrong?
In drafting my post, I inverted the actual and expected; here they are again, correctly titled: ACTUAL RESULTS Option 1: Transaction 1 returned. *Option 2: Transaction 1 returned. *Option 3: No transaction returned. *Option 4: Transactions 1, 2, and 3 returned. *Option 5: Transactions 2 and 3 returned. Option 6: Transactions 2 and 3 returned. * erroneous EXPECTED RESULTS Option 1: Transaction 1 returned. Option 2: Transactions 1 and 2 returned. Option 3: Transaction 2 returned. Option 4: Transactions 1 and 3 returned. Option 5: Transactions 3 returned. Option 6: Transactions 2 and 3 returned. All can be reproduced.
Chances are other higher priority bugs are being addressed; however, this one is simply a major impediment to querying transactions. Hoping that something is on the horizon to straighten out the Date Posted functionality so that it retrieves transactions correctly.
Bob Fewell is looking at date boundaries in relation to reports and brought this up on gnucash-devel. We'll probably get rid of 1 and 5 as redundant: One can easily enough use "on or before" to get "before" by adjusting the date one day; same for "on or after" and "after".
Created PR399 to fix this and will hopefully get merged for the next release. In the end I have left all search options for for the reason pointed out by Geert.
The PR has been merged in our sources. The fixes will appear in gnucash 3.3. Thank you for reporting this and feel free to report any other issues you encounter.
Yay! All six options now return results as expected! Thank you much, all. Gnucash 3.3
