Until the last update I was able to use a wildcard in a date field for use in an =SUMIFS formula
Formula:
The below formula sums everything in J105-J1000 IF M105-M1000 = C3 AND E105-E1000 = E1
Here is the formula:
=SUMIFS(Checking.J105:J1000,Checking.M105:M1000,C3,Checking.E105:E1000,E1)
This is the contents of E1 is 10/*/21 and the formula returns a 0
If I change E1 to 10/1/21 the formula returns a sum correctly
Thanks DW
If you would store formatted day numbers instead of date strings, you could use all the magic features of your spreadsheet software.
Month_Person_PV.ods (52.2 KB)
Usually this should not change on update, but the first point I’d check is options for Calc, because it has to be decided, if you are allowed to use wildcards or regular expressions or neither of them are allowed.
For english language options are on the Tab LibreOffice_Calc → Calculate as you may see on the screeshot @eeigor has posted.
I’m surprised myself. But the asterisk works. Works everywhere.
The date format is as follows: DD.MM.YYYY
Criterion: DD.*.YYYY
Untitled 1.ods (16.6 KB)
As already explained in the IRC channel today, specifying criteria that evaluate the formatted string of data values is fragile and thus a bad idea. The example 10/*/21 (assuming the 10 is month number for October) works as intended only if the date format is MM/DD/YY, not if it was a default format and document is loaded in another locale that uses DD/MM/YY or YYYY-MM-DD or not even if it’s reformatted to MM/DD/YYYY and recalculated.
The proper solution would be to use one of
=SUMPRODUCT(Checking.J105:J1000;Checking.M105:M1000=C3;MONTH(Checking.E105:E1000)=10;YEAR(Checking.E105:E1000)=2021)
or
=SUMIFS(Checking.J105:J1000;Checking.M105:M1000;C3;MONTH(Checking.E105:E1000);10;YEAR(Checking.E105:E1000);2021)
the latter entered as array formula (close with Shift+Ctrl+Enter).
Simpler solutions are also possible.
If the date in E1 is 10/01/2021, then (example)
=SUMIFS(B1:B10; A1:A10; ">=" & E1; A1:A10; "<=" & EOMONTH(E1;0))
At some point, it will be necessary to summarize the data for a week, so it is best to always explicitly set the beginning and end of the date interval.
Both again create a criterion that evaluates formatted string results, not data.
Update:
My bad. This does a concatenation of the operator and the date serial number, not the string of the formatted date. Iff the content of E1 is in fact a date, not a string that looks like a date.
This is all strange. Cell E1 contains a number and the formula should take this into account. In Excel, for example, the cell format is not taken into account when calculating formula values. Let’s state explicitly:
=SUMIFS(B1:B10, A1:A10, ">=" & N(E1), A1:A10, "<=" & N(EOMONTH(E1,0)))
BTW, in my LO 7.1.6.2 en_US Ubuntu 20.04 the formula
=">=" & E1
gives an error value (Err:501).
In LO 7.2.1.2 ru_RU Win 10 formula value is >=44470
Is it a bug?
Update: Bug in the author’s head - see below.
Tried in 7.1.6 and can’t reproduce. Concatenating valid operands with the & operator should always produce some result. Make sure you entered the expression exactly as stated here, Err:501 is usually an unexpected invalid character, for example if you use typographical quotes instead of " straight ASCII ones.
Yes, thanks, it was - the forum kindly and imperceptibly changed the type of quotes. 
Same in Calc in this constellation. See the update in my earlier comment.
Here you must use preformatted text (Ctrl+Shift+C) for formulas to avoid the typographical quotation marks.