IrdRule 06 compares strings not dates

[Gary Kennedy]

The implementation of IrdRule 6, at around line 407 of IrdRules.java, has a
check that firstPaymentDate is greater than effectiveDate, however it is
comparing Strings, probably it is safer to Date objects.

I mean replace
if ((payment == null) || (effective == null) || greater (payment, effective))
with
if ((payment == null) || (effective == null) || greater(toDate(payment),
toDate(effective)))

IrdRule 21 has a similar check and is comparing Dates rather than Strings.

Gary

Gary

[Andrew Jacobs]

Thanks for spotting that. Its corrected in the repository and will be included
in the next build.

[Gary Kennedy]

Not sure it is a bug now. If you search the IrdRules.java file for use of the
static method

boolean greater (final Node lhs, final Node rhs)

It is used in quite a few other places when comparing dates. Im thinking they
are not all bugs, i suppose it is relying on the fact that the dates are
already checked and are in ISO format (can that be guaranteed at this point)?
and so string comparison is actually fine, even if it feels distinctly odd?

Here are some more examples where greater is used to compare dates by string
comparison, similar cases are also in IrdRules.java for less, lessOrEqual

Gary

Rule14 line 734
if ((termination == null) || (effective == null) || greater (termination,
effective))

Rule15 line 778

if ((termination == null) || (periodStart == null) || greater (termination,
periodStart))

Rule 16 line 822

if ((termination == null) || (periodStart == null) || greater (termination,
periodStart))

Rule17 line 866

if ((termination == null) || (periodEnd == null) || greater (termination,
periodEnd))

Rule18 line 910

if ((periodEnd == null) || (periodStart == null) || greater (periodEnd,
periodStart))

Rule 20 line 998

if ((last == null) || (effective == null) || greater (last, effective))

Rule 33 line 1721

if ((termination == null) || (effective == null) || greater (termination,
effective))

[Andrew Jacobs]

If the two dates have no time duration offset then a string comparison will
yield the correct result as the strings are in YYYY-MM-DD format but it should
really use the Date based implementation.