After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 523250 - SUMIF database values should be interpreted
SUMIF database values should be interpreted
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Analytics
1.8.x
Other All
: Normal minor
: ---
Assigned To: Morten Welinder
Jody Goldberg
: 417305 531111 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-03-18 21:41 UTC by Matthijs Kooijman
Modified: 2008-05-04 00:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Gnumeric file showing the problem (1.94 KB, application/x-gnumeric)
2008-03-18 21:43 UTC, Matthijs Kooijman
  Details
Tentative patch (9.86 KB, patch)
2008-03-20 23:49 UTC, Morten Welinder
accepted-commit_now Details | Review

Description Matthijs Kooijman 2008-03-18 21:41:01 UTC
Please describe the problem:
I'm having a problem with sumfif: Cells (and/or conditions) that contain dashes aren't matched properly. 

Ie, if I have the string '2007-2 in a cell and use "2007-2" as a condition, the cell is not matched. This seems to be specific to the use of only numbers and dashes, the problem does not occur when other characters (such as letters or a plus sign) are added.

I don't have Excel around for comparison but I think I have seen this working on Excel before. It was working in gnumeric 1.6 at any rate.

Steps to reproduce:
See attachment for a few examples. Every column that has 6 in the last row is correct, every column with a 0 is incorrect.

Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Matthijs Kooijman 2008-03-18 21:43:36 UTC
Created attachment 107570 [details]
Gnumeric file showing the problem
Comment 2 Morten Welinder 2008-03-18 22:47:58 UTC
The problem is that the value you search for ("2007-2-1") gets interpreted
as a date and gnumeric ends up searching for the corresponding value,
i.e., 39114.

Some testing is required to determine what the correct behaviour is,
i.e., when and what should be interpreted.
Comment 3 Morten Welinder 2008-03-20 23:49:53 UTC
Created attachment 107714 [details] [review]
Tentative patch

This patch is a little bit bigger than I hoped for, but we need the date
conventions in order to do the matching right.
Comment 4 Jody Goldberg 2008-03-23 17:00:15 UTC
Seems reasonable.  Passing in the DateConvention is a tad ugly but there's not much choice now.   In time we she probably just move to a 'Context' to hold all the different conventions and position information.
Comment 5 Morten Welinder 2008-03-25 00:24:01 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 6 Morten Welinder 2008-03-27 16:57:11 UTC
*** Bug 417305 has been marked as a duplicate of this bug. ***
Comment 7 Morten Welinder 2008-05-04 00:11:45 UTC
*** Bug 531111 has been marked as a duplicate of this bug. ***