nus-se-bot
commented
4 months ago Team's Response
This was intentional, as in the rare case where users think it is a leap year and want to set the date to 29th February even though its a non existent date, we allow them to do so as we are implying that they mean that the order is to be completed at the end of the month. If the date were to be lets say 32/02/2024. The program will return an error, the only times it allows the user to input a date with the day up till 31, as we imagine the user still wants the order to be created for a date towards the end of the month. If they later find out when the deadline is near that they needed an extra 1 or 2 days to fulfill the order, they can simply postpone the deadline by editing it using the edit command. Hence we feel that the issue should be of severity low, as it rarely affects the users workflow when using the app.
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: Thank you for your response.
However, I disagree.
It is not expected behaviour for an application to make the assumption of the user's intended input rather than handle it as an error. By accepting a non-existent date, the user would reasonably assume that the date they have inputted would be accurately displayed rather than changed by the system (unless otherwise stated -- which the UG did not mention nor warn users about). Even if warned about such a thing, this is an inaccurate way of handling erroneous inputs that would greatly inconvenience the user.
For example, if a user erroneously inputs 29/02/2025 when they had wanted to type 29/02/2024, the mistake could have been easily corrected if there were handling of non-existent dates. Instead, the user will believe they had inputted the date correctly and may not discover the error until much later. They may even be confused that there is an order for 28/02/2025. Especially for a business, this could be detrimental as these deadlines are essential in the user prioritising their time and knowing when to contact the customer.
Furthermore as mentioned in the team's response, there is already error handling expected for certain non-existent dates past "31" as a date. There is no particular reason why it should not be extensive enough to cover the level of validation required for dates inputted, and instead leaves such errors to be quietly uncaught by the system. Despite this seemingly being a 'rare' case, it is actually quite common as the application handles dates such as 31/04/2024 in the same way, by displaying 30/04/2024 instead.
__ To recreate such an error
-
Create an order for John Doe :
order p/98765432 by/31/04/2024 -
Add the product:
product m/1 pq/1
The order would be created as such, with the date changed to 30/04/2024
__
This suggests that for months without a 31st date, and for February which may or may not have dates past 28th, these situations would be handled in a similarly unexpected manner. Such a functionality would hence not work as expected by the user, and leave them without any error message to prompt them of their mistake. It would cause significant inconvenience to the user, and an incident like this may cause a lack of trust in the application's error handling. These would also apply to the error handling of editing deadlines.
Hence, I believe this functionality bug should be classified as severity.Medium.
If i try to edit the deadline to a non-existent date like 29/02/2025, it doesn't give an error. Instead it changes the deadline to 28/02/2025. Unexpected behaviour that could cause confusion.
The deadline has changed to 28/02/2025 instead.