type='date' calculation does not convert number to date

[MartijnR]

Software versions

Collect 2021.2.4

Problem description

This form causes an "No partial converter found for type: java.lang.integer" exception after filling in a date and continuing to the next page (XLSForm here)

date-calcs-javarosa-bug.xml.txt

It's this line:

<bind calculate=" /data/d  + 1" nodeset="/data/calc-date-inline" readonly="true()" type="date" />

Expected behavior

For the calculation result to be converted to a date like 2021-12-01.

Other information

Not sure if this belongs under Collect or JavaRosa. I guessed.

I realize this use case may be considered too obscure, but I happened to notice it so wanted to report it.

[neal0892]

Trying to reproduce

[lognaturel]

You’ve been on some fun 🗓 adventures 🕰, @MartijnR! This is absolutely the right place to file. Looks like an underlying type coercion issue to me.

@neal0892 an ignored test to formally document the limitation would be most welcome. My hunch is that the fix will not be a good candidate for a first PR.

[neal0892]

@lognaturel that makes sense to me ...thanks

[dimwight]

You could just insert the date() function:

<bind calculate="date( /data/d  + 1)" nodeset="/data/calc-date-inline" readonly="true()" type="date" />

Updated Excel master date-calcs-javarosa-bug_.xlsx

[lognaturel]

That's very interesting, @dimwight. The type is supposed to be inferred based on the field type. It's extremely odd that forcing the type outside of the expression makes a difference and maybe that's a hint as to where the problem is. I would expect /data/d + date(1) to work but wouldn't be surprised if it didn't either. My guess is that this is a significant rabbit hole.

[dimwight]

I've been exploring further how JR handles dates, partly stimulated by the work that resulted in #652. Without even delving into the code it looks like some sense can be made of the underlying logic.

It's easier to look in the hierarchy view to see what's going on. So in the form defined by date-calcs-651.xlsx you can see clearly which calculations evaluate to numbers and which to dates.

• calc_0 and calc_1 show that a path to data /data/d and a reference ${d} evaluate equally to a date - which makes sense since no actual calculation is being performed.
• calc_2, calc_3 and indeed calc_4 show that a substantive calculation evaluates to a number rather than a date; and calc_5 that of course the number can be passed to a further calculation.
• calc_6 shows that an arbitrary number can be converted to a date.

Since this all perfectly logical and enables arbitrary calculations on dates, perhaps the current code is adequate?