Team's Response

Hi, thank you for raising this issue. We noticed this behaviour. It was left as intended as we find it reasonable for the system to auto-correct 29th February to 28th February on non-leap year as we believe entering 28th or 29th.

As our application aims to allow users to track their tuition appointments and personal schedule, it's rather impossible for them to plan a tuition date with a tutor or perform a task on a day that is non-existent in the first place before keying into our application. The tutor would have rejected it in the first place, which is not the responsibility of our application. Not to mention that our Timetable and Calendar View Panel will not display it as a valid date as well.

However, we did consider the fact that the user may have mistaken the last day of the month to be 29 instead of 28 on certain years. Hence we intended to leave date auto-correction as part of our application function so that the user does not have to keep track whether how many days are there in the current year's February.

It is considered a documentation bug since we should educate the user about February not having more than 29 days, and it will be automatically parsed into 28th by the system, which actually we did so, but it was accidentally discarded during the finalization of our UG.

Since we only have one description box that describes in regards to schedule's attributes limitation, we will be grouping all the Schedule's Leap DateTime related bug together as it deemed to be caused by missing documentation from the same section. If we have to consider this as a functionalitybug, then it should be considered duplicates from the other Schedule's Leap DateTime as it is caused by the same defect and cannot be fixed independently. We will consider this a rare occurrence, and it doesn't hinder the performance of other operations or commands; hence, we accept it at Low severity.

The 'Original' Bug

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

No description of date auto correction in the User Guide but dates for leap years seem to be autocorrected

When I type in the following command: add_reminder ds/Tuition Payment Due d/2023-2-29 with an invalid date, the date is autocorrected to 2023-2-28 as can be seen below:

However, I can't see any mention of this autocorrection in the user guide and it might be confusing for users who might have accidentally keyed in the wrong date. I think it should be made clear in the user guide that such a feature exists.

_{[original: nus-cs2103-AY2021S2/pe-interim#1934] [original labels: severity.Low type.DocumentationBug]}

Their Response to the 'Original' Bug

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

No details provided by team.

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 type

Team chose [type.DocumentationBug] Originally [type.FunctionalityBug]

[x] I disagree

Reason for disagreement: I believe this should be handled appropriately because if the user mistakenly schedules a schedule 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 a schedule on the wrong date. This should definitely be handled.

In the case where you have mentioned, it is handled to auto correct to the date before (not particularly in agreeance, and would agree to auto correct to the date after) then it should definitely be included in the UG. Whichever decision you make, it would be best to make it clear to the user through the user guide. Thank you for replying to my response!

:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

[ ] I disagree