No error message when invalid date used (e.g. 29-02-2023)

[lynnetteeee]

Description Set the context.

No error message when invalid date used (e.g. 29-02-2023) in adding contacts.

Steps to reproduce

1. Launch the application for the first time to load initial data.
2. Run add ic/S9987654A n/Mary Ann g/F b/29-02-2023 p/94567890 e/maryann@gmail.com d/General Flu

Expected behaviour

Error message to indicate non-leap year

Actual behaviour

Added, but rounded off birth date without notice.

Reason for severity

Brings inconvenience to users when they make a typo, which is highly possible, but did not know that they made a typo e.g. supposed to be 19 Feb. \

[nus-pe-script]

Team's Response

Duplicate of #5289

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

ADD Feature does not match the expected behaviour of data handling

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:

---

_{[original: nus-cs2103-AY2324S2/pe-interim#5074] [original labels: type.FunctionalityBug severity.Medium]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

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 duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** I still think the bug is of `type.FeatureFlaw`, because the course website stated that the lack of handling invalid inputs can be considered a feature flaw but did not say that it can be a functionality bug. 

---