GNOME Bugzilla – Bug 607185
gnc-fq-helper: Need better handling of missing date
Last modified: 2018-06-29 22:33:32 UTC
If for whatever reason finance-quote is unable to get a date for a quote or to convert it to the standardized form, gnucash is unable to use the otherwise correct quote. With web pages being updated definitively more frequently than finance-quote, this is quite a nuisance. Up to now, gnc-fq-helper emits an error message + the quote, a combination gnucash is unable to process. The following patch presents a workaround: --- /usr/bin/gnc-fq-helper.orig 2010-01-16 23:09:40.000000000 +0100 +++ /usr/bin/gnc-fq-helper 2010-01-16 23:09:50.000000000 +0100 @@ -221,6 +221,12 @@ $parsestr = ParseDateString($parsestr); my $result = UnixDate($parsestr, "\"%Y-%m-%d %H:%M:%S\""); + if(!$result) { + #fix date handling for quotes with no date: assume local date + (my $second,my $minute,my $hour,my $dayofmonth,my $month,my $year,my $dayofweek,my $dayofyear,my $daylightsaving) = localtime(); +# $result = "\"".sprintf("%04d-%02d-%02d %02d:%02d:%02d",($year+1900),++$month,$dayOfMonth,$hour,$minute,$second)."\""; + $result = "\"".sprintf("%04d-%02d-%02d",($year+1900),++$month,$dayofmonth)." 12:00:00\""; + } if($result !~ /^\"\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d\"$/) { $result = "failed-conversion"; } I would prefer using the current date + 12 hours rather than current date + time, but this is open for discussion. gm
Committed to trunk, r18575 - thanks a lot! (I've inserted some whitespaces to make the long line easier to read.) In the future, please attach patches as attachments here because otherwise the linebreaks will not be transported correctly here. Again thank you very much for this patch!
http://lists.gnucash.org/pipermail/gnucash-devel/2010-January/027200.html , Frank Ellenberger writes: I have the following problem with this patch: Let us assume, I have a crontab entry 0 8 * * 1-5 gnucash --add-price-quotes $HOME/<GnuCash-Filename> > /dev/null 2>&1 and I had some fund, which would publish his NAV each workday at 20:00. Then the normal Monday run would result in the date of last Friday 20:00. With this patch, the result would be Monday 12:00. It would be shifted by 3 days. Assume further, at tuesday the problem is fixed. Then I would have 2 different Monday entries. The second point is the fixed time: somebody else might have an entry 0 * * * * gnucash --add-price-quotes $HOME/<GnuCash-Filename> > /dev/null 2>&1 In a volatile market she would get up to 24 really different rates with the same timestamp. Confusing? Yes, at least for me. Or should 12:00 indicate estimated date, time unknown? Is there no other way to indicate an estimated timestamp?
What was the original behaviour? The quote couldn't be used, but all other quotes were used correctly? Frank's response indicates this is more or less the correct behaviour, because inside gnucash, there is no distinction between "actual date" and "current date" of a quote possible. Hence, it was probably better to ignore the quotes without date completely.
To my experience, these bugs are not fixed quickly, because they require an update of finance::quote. This has been available every half year or so in the last year. In my case, I got fed up after about 1,5 months without a quote for one of the funds I own and wrote this patch. Tried fixing finance::quote before, of course, but couldn't find the bug. As I had the same problem several times before, I thought a generic solution would be more appropriate. Original behavior was asking whether to ignore the error and proceed with the other queries. Regarding the 12:00 time stamp: This was copied from some lines above, it is standard gnc-fq-helper behavior if no time can be found. I'm open for other suggestions here. @Franks first example: Yes, that's right. If the Friday evening quote contains no date and you query on Monday morning, you would end up with a virtual Monday noon quote. If the bug was fixed on Monday night, you would get an additional (correct) Monday evening quote. A heuristic sanity check could be included (something like: stocks are traded on weekdays from 9-4 only, so use the last reasonable previous date). @Franks second example: could be amended by using the actual local time instead of 12:00. The line is included in the patch but commented out.
I did not explore the relevant code, but I think, the clean solution would be, to encapslulate the currently used date in a new structure retrieved_date with an additional status word: 0: correct retrieved 1: estimated - replaced by locale time of query some other? But I assume that would be some work until it would be visible in the GUI.
@Frank: Even if we solved the problem of how fq-helper marks a date as "estimated", we still are stuck with the problem that gnucash doesn't know of "estimated dates". In gnucash there is no notion of estimated vs. accurate date, so this distinction isn't useful right now - it would require large changes in the gnucash GUI, which we won't have right now. Thus the question is, what can we do even if gnucash doesn't distinguish the estimated from the actual dates? There were some proposals in comment #4. Which of those should be implemented and would be an improvement?
A quick solution would be, to ask the user, e.g. by an option edit->Preferences->finance-quote->estimate date with a tooltip "Should Gnucash accept quotes with a broken date and store them with the current date/time stamp?" with Answers: 0: never (default, because old behavior) 1: always optional 2: ask each occurrence (would require an additional dialog)
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=607185. Please continue processing the bug there and please update any external references or bookmarks.