Team's Response

Duplicate case.

The 'Original' Bug

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

Leap year is not accounted for when adding appointment

Input: add_appointment n/Bernice Yu s/English d/2022-02-29 fr/10:00 AM to/12:00 PM l/Bedok

I expected an error message, but what was worse is that it added it, with date as 2022 28 Feb

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

Their Response to the 'Original' Bug

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

2022 is not a leap year.

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)

[x] I disagree

Reason for disagreement: Not a duplicate of the given issue. My issue is concerning the adding of an invalid date 29 Feb 2022, into the application which should not happen, and not about leap years.

:question: Issue response

Team chose [response.NotInScope]

[x] I disagree

Reason for disagreement: I believe this should be handled appropriately because if the user mistakenly schedules an appointment a day after 28 Feb 2022 as 29 Feb 2022 instead of 1 March 2022, then the application should be smart enough to flag this as a warning or an error instead of correcting it to 28 Feb 2022. If the user were not to double-check the command feedback box for the actual intended date, then the application would have mistakenly scheduled an appointment on the wrong date. This should definitely be handled.

chwoozy / pe

Unexpected handling of edit_appointment case #9