Community
Participate
Working Groups
Created attachment 94811 [details] Product Sales by Country.rptdesign Open the attached report that uses the Classic Models sample database. Preview it. Notice on the line for Australia, NSW, the change is "-0". This is probably due to rounding errors. The value is probably something like -0.1 which, when rounded to no digits past the decimal displays as 0, but the negative calculation is done off of the original value. The only problem is, aside from cryptic computer math cases, -0 is the same as 0 and is displayed as 0. The workaround, I guess, is for me to do my own rounding in the expression for the field, but this means that the field no longer holds the actual number an can affect downstream uses of that field. Plus, it is just more work for the developer. Expected that BIRT would do the right thing for me. If I specify rounding (by saying 0 digits past the decimal point), BIRT will round the number first, THEN apply the negative sign if needed. This is the technique used in most other software, such as Excel.
By viewing the attach design, it is -0.24 that has been round -0. It is an issue in number format. Please know to use the attached design in 2.3. Need to manually change dataSetRow["ORDERDATE"] to new Date(dataSetRow["ORDERDATE"].getTime()). Detail reasons seen in https://bugs.eclipse.org/bugs/show_bug.cgi?id=226409.
I used latest 2.3 and replaced all the string as Rick mentioned, but I don't get something like -0. In fact, the change value I get is either 0 or NaN. On the line Australia-NSW, the change value is NaN. Paul, could you try the latest build?
BIRT uses the java's DecimalFormat to format the number, the #,##0 do generate -0 in this case. I think -0 is acceptable is this case, see http://en.wikipedia.org/wiki/%E2%88%920_(number) and http://java.sun.com/j2se/1.4.2/docs/api/java/text/DecimalFormat.html
It is unfortunate that the underlying Java code has a bug. Still, the issue here is that business users of reports don't expect to see a -0 or (0) in the report output. As a result, someone will have to implement a workaround. As it is now, it is each report developer who must 1) discover the problem, and 2) devise a workaround. This is one of those cases where there is really only one right way to solve the problem. Rather than forcing each report developer to figure out that solution, it would be much better to devise the workaround only once and implement it in the core BIRT code. Just to be clear, the request here was to make the output be correct for what business users expect. If third-party code that BIRT chooses to use does the formatting wrong, then the request is to work around or fix the problem so that report users get the result they expect.
It is very easy to reproduce this bug in BIRT 2.2 with a very simple design. You don't need the original example report, if that report is no longer compatible with later BIRT versions. 1. Create a new report. 2. Drag a Data Item from the palette. Set its value to -0.001 3. Using the property editor, go to the Format Number tab. Choose Currency. 4. Preview. The data item value is shown as -0.00
Both the NumberFormatter in Java and ICU are all create the result as -0. To resolve this issue, BIRT need re-write the number format package completely. BIRT can't fix this issue by checking the result to see if it is -0 as the user can generate such result explicitly as: #.##;-#.##. defer to future to see if ICU or JAVA could fix this issue.
Fixed. Checked in on Apr 28.
verified on build 2.5.0 v20090430-0630.-0.001 will be displayed as 0.00 if only two decimals are allowed.
