ADD Feature does not match the expected behaviour of data handling

[yleeyilin]

Steps to reproduce:

• As per the UG, I have inputted add ic/S0944567D n/John Doe g/M b/29-02-2023 p/98760432 e/johnd@example.com d/Penicillin|\nCephalosporins i/Infectious Diseases i/Genetic Disorders.

Expected:

• I was expecting to get an error message since 2023 is not a leap year and 29th Feb only exists on leap years.

Actual:

• However, I got a success message instead.
• This is problematic as this is not a valid input and should have been caught by the system to ensure that information are keyed in correctly.

Screenshots:

[nus-pe-script]

Team's Response

The team has actually noted about this issue prior to v1.4 and the application instead ensured to not have an overzealous validation for the date and instead have a "feature" such that it would automatically parse invalid dates into the nearest valid date. In the example, 29-03-2023 is parsed to 28-03-2023 under the hood. Perhaps in future releases, we would include warning messages as well to make it clearer. So as of now, we would accept it as NotInScope and of Low Severity.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: Referencing the TP guidelines to what it means to be not in scope, it has to not be related to the features done in v1.4.

However, I believe that handling invalid date is quite within the scope since your product uses date as an attribute of your contact. Given that it is an entire attribute on its own, it should and must be handled correctly.

In fact, parsing 29-03-2023 to 28-03-2023 without any warning could hinder the users who may not even realise that they made a mistake. This combined with the fact that the date is not even mentioned in the command output box could make it worse for the users themselves.

There is no reason as to why this is considered "overzealous" validation. Avoiding overzealous validation means that catching does not value add to your product, whereas not catching it does value add.

Here, it is clear that it does value add to catch such invalid input.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---