search

kimberlytmq / pe

0 stars 0 forks source link

Automatically changing appointments on some invalid days (30th and 31st), while throwing errors for other invalid days (32nd) #4

Open kimberlytmq opened 1 week ago

kimberlytmq commented 1 week ago

While it is mentioned in the UG that some dates such as 29nd Feb and 30th Feb will be changed to the nearest date in the month, while other invalid dates such as 32nd Feb will be rejected, it doesn't make sense to have different approaches to handling invalid dates. It can also be confusing to users when their keyed in dates are changed without any warning or error as shown below.

Key in appointment for index 3 on 31st June. image.png

Entered appointment date is 30th June. image.png

nus-pe-script commented 1 week ago

Team's Response

Thank you for your input. As stated in the User Guide, "Dates entered on an invalid day (e.g. February 31) are automatically adjusted to the nearest valid day in the specified month. However, dates exceeding the maximum possible (e.g. the 32nd of any month) will result in an error.". As the invalid days specified here could be due to a careless mistake, we have decided to make it easier for the users by automatically rounding it off. However, a date exceeding the maximum possible is more clearly a user error (i.e. they mistake the purpose/usage of the command) and hence we decided to show an error there instead. We could have a warning message to alert the user, however due to having already stated this issue in the User Guide, we have decided that the effort to implement this does not match the benefit it provides in this current iteration.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: It does not make sense to help users round off dates for some invalid dates and throw an error for others. If users key in 32nd, it can also be argued that it could have been a careless mistake (typing 32 instead of 31), and by that logic it would be rounded down as well. Having different ways of handling invalid dates can be misleading and confusing for users, especially when no error or warning is thrown for some invalid dates before it is rounded. In the guidelines, it is mentioned that it is considered a bug if it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort. Since there are only a few dates that get rounded (29 feb, 30 feb, 31 feb, 31 april, 31 june, 31 sep, 31 nov), exceptions can be made for such cases, so that a warning or error is thrown.

image.png

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