GNOME Bugzilla – Bug 541970
Balance Sheet: "Nearest in time" exchange rate not correct
Last modified: 2018-06-29 22:06:50 UTC
Please describe the problem: The nearest in time exchange rate (of a stock) is not correctly chosen in the balance sheet report - provided that "nearest in time" means that the value in database with minimum time distance to balance sheet date is allowed for.. Steps to reproduce: Enter fair values of stock into price database: July 1: 100 July 4: 90 July 5: 90 Run balance sheet report at July 2 with price source "nearest in time". Actual results: Fair value of stock: 90 Expected results: Should be 100. Does this happen every time? Yes. Other information: Example file provided.
Created attachment 114157 [details] Nearest-in-time bug in balance sheet report
Created attachment 114160 [details] Sample file reproducing the bug Confirmed. I can reproduce this problem with the sample attached.
I've dug through the code and here's what's actually happening: Report time: July 2, 12PM (noon) Time of July 1 price: July 1, 12AM (midnight) Time of July 4 price: July 4, 12AM (midnight) So the difference between the report time and the price time is exactly 36 hours in both cases. So it is a tie, and the newer price (July 4) is chosen arbitrarily. So that explains what happens... now what to do about it?
In both samples attached to this bug report the time stamp of the July 1 price is - 2008-07-01 00:00:00 +0200 (Charles' sample) - 2008-07-01 09:00:00 +0200 (my sample) I am wondering if the time of the prices is ignored in the calculations in the reports. If so I am just asking which rate is taken when multiple entries are in the price-db with the same date. This case happens after a multiple update during a day. I would expect the latest entry to be taken. Only if the latest entry is not used there is an issue here I think.
I don't think the time is ignored. If it was judging by date alone then it would pick the July 1 price. I'll bet your report time was 2008-07-02 21:00:00 +0200, making your July 1 and July 4 prices both 36 hours from report time, just like mine. (The nine hour difference in our samples is probably our time zone difference.) Anyway, if GnuCash has fake times of day on Price Editor entries and report run dates, then the "Nearest in time" routine could ignore time of day and only compare dates. But maybe the "Nearest in time" routine should be left alone, and the real bug to fix is the fake time of day. So I'm not sure what the right approach is here. We might need to ask for advice on the mailing list.
You should watch, not to run in Bug 137017 - date of transaction change with time zone change, which possible also relates to Bug 506251 – src/engine/test/test-date fails on systems with a timezone east of UTC. May be, gnucash files need an option to remember, in which time zone they were created?
(In reply to comment #6) > You should watch, not to run in Bug 137017 - date of transaction change with > time zone change, ... Even the winter/summer time switch counts as time zone change, but it should not result in significant distortions of report results, I assume. > May be, gnucash files need an option to remember, in which time zone they were > created? This is ok if transactions relate to one time zone regardless in which time zone they are produced. But what happens if stock or currency exchange data are retrieved online in a different time zone than assigned to the gnucash file? This sounds like a complication, e.g., with respect to use closing data only.
Fix committed as r17454. Requesting backport for 2.2. This fix works by preferring the older price in the event of a tie. Even without this bug, I think it makes more sense anyway. A price that actually existed at the given time will be preferred to one that didn't. Another way of saying this: If the "nearest in time" method results in a tie, then the result will be equal to the "latest before" method.
Applied to branches/2.2 as r17520 for inclusion in GnuCash 2.2.7. Thanks a lot!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=541970. Please update any external references or bookmarks.