Created attachment 373016 [details] Screen show showing wrong dates On the networth linechart report, if I select end of month for the end date, this is not what is displayed, it seems to fall a week or two short. It also appears that the start date is not accurately followed - in the screen shot attached I seem to get an extra month at the beginning.
Created attachment 373037 [details] not reproducable on Ubuntu 18.04.1 On Ubuntu 18.04.1, with a very simple test file, this is not reproducible using the default report settings (see screenshot). Did you change any other settings?
I can't think of any other changes I have made that would have affected this. I am using Windows 10.
Carsten, your chart looks different from the gnucash jqplot charts. Do you perhaps have Christopher Lam's experimental chartjs branch built on your system ?
@Geert this is just jqplot with a bgcolor in stylesheet. @Lloyd - would be good to experiment with a few more charts eg income-expense chart, category-barchart; different date ranges. This will help pin down whether bug in report or charting engine. Also: OS, timezone. Also: consider exporting the .html report (File > Export > Export Report) so we can analyze. There should be no confidential data in the .html report - only the chart numbers that have already been reported here :)
Created attachment 373039 [details] networth 1/8/17 to 15/11/8
Created attachment 373040 [details] Networth 2/8/17 to 15/11/8
Created attachment 373041 [details] Networth 2/8/17 to end of October 2018
Created attachment 373042 [details] networth 2/8/17 to 31/10/18
Created attachment 373043 [details] networth 2/8/17 to 1/11/8
Created attachment 373044 [details] income expense 2/8/17 to 31/10/18
I've attached a number of screen shots, where generally I have altered the limits by a day. There are also a couple where one is 31/10/2018, and one is end of the month. windows 10 Pro 1803 Build 17134.345 Timezone GMT
Created attachment 373045 [details] Network exported to html
Created attachment 373046 [details] render on my laptop On my laptop the chart does render properly. I wonder if there is something changed about your timezone or local environment which has triggered a jqplot bug. Are other charts affected? eg Asset Chart, Transaction Report etc.
Chris, did you try setting your TZ to UTC?
Just did on Ubuntu - still works.
Chris, if I understand correctly, you've taken my html and rendered on your laptop? Actually, I've just done the same, and it seems to render ok. chrome and Edge. I'll post a screen grab showing the gnucash render compared to exported file rendered in Chrome.
Created attachment 373047 [details] Same report rendered in gnucash and Chrome
Income Expense Line chart seems to render wrong, another screen grab attached) Assets over time (bar chart) renders ok. As a line chart there is a difference. (A rnage that shows the issue is 1/8/2017 to 15/11/2018) So I believe the problem is associated with line charts.
Created attachment 373048 [details] income expense comparison
I can't reproduce your bug, I suspect it's still a genuine bug in jqplot, being manifested in either gnucash renderer or chrome/edge renderers. At the core of this is a fundamental difference in handling between bar and line charts. Barcharts are always "x=categories y=value" Linecharts are typically "x=value y=value" In gnucash, linecharts the x-values are sent as date-strings. jqplot interprets the date-strings as dates and attempts to plot "x=timeline, y=value". However, in practice, linecharts are always being used as "x=categories, y=value" - after all, all built-in linecharts are sending regular periodic dates (e.g. jan-18 feb-18 mar-18 etc) therefore it's rather pointless to try map out these x=values into exact regularly-spaced x-coordinates. It would be more clever to force the linecharts to be separate categories and the problem will disappear. I think the above explanation makes sense?
Addendum may be a bug in one of the timezone configs rather than jqplot strictly. But making linecharts xaxis 'categories' will still solve it.
As an experiment try the following minor changes to html-linechart.scm @@ -425 +425 @@ - (push (gnc:html-js-include "jqplot/jqplot.dateAxisRenderer.js")) + (push (gnc:html-js-include "jqplot/jqplot.categoryAxisRenderer.js")) @@ -487 +487 @@ - renderer:$.jqplot.DateAxisRenderer, + renderer:$.jqplot.CategoryAxisRenderer, And let me know what you think!
That makes a difference. Plots now seem to start/end in the correct place. However, it now tries to create an x-axis label for each data point, and if step size is day, you can't read a thing. Also, date format for the labels is now wrong. Two screenshots attached to show this.
Created attachment 373049 [details] Using Category axis, step size day
Created attachment 373050 [details] Using Category axis, step size 2 weeks
This is because 1. barcharts have mechanism to skip labels, and linecharts have never needed them so far -- see getVisualTicks() in the barchart html. 2. linecharts, as described above, used x=date-string and needs to be interpreted by jqplot as a date, and consistent across all timezones and all dmy/ymd/mdy combinations. Therefore reports usually sent iso-dates (yyyy-mm-dd) to jqplot so that the strings could be decoded correctly. In any case I'm not 100% happy with coding the fix as above, because there are larger changes afoot to the charting infrastructure and this 'bug' will disappear if the chart reporting engine is merged in later on. Perhaps meanwhile this bug can be left open for now. I still believe the underlying reason is something to do with date/string decoding and jqplot interpretation of dates, and jqplot's choice of min and max values for the dates.
@Lloyd -- you can try the 3.900 beta master builds - https://code.gnucash.org/builds/win32/master/ they have been upgraded to use a current-gen chartjs rather than obsolete&antiquated jqplot. Please note these beta builds will potentially change the datafile format to be incompatible with 3.x series therefore do not trigger *save-file* at all. The linecharts should now be sane.
This is apparently fixed in the 4.x series. If you encounter similar problems please open a new bug.
