Currently, it has been documented that when provided an invalid date such as 31/02/2025 (February only has 28 days in a non-leap year), the system sets it to the nearest valid date instead of rejecting it.
I feel that a warning should also be given to reflect the system's action and decision. This is because the invalid date could have been a result of the user's mistake in typing in the month.
For instance, a user intends to schedule an appointment for a workshop from 31st May 2024 to 14th June 2024 but accidentally enters 04 instead of 05 resulting in:
sched 5 --title=Workshop --from=31/04/2024 15:00 --to=14/06/2024 15:20 --addr=VivoCity
when it should have been
sched 5 --title=Workshop --from=31/05/2024 15:00 --to=14/06/2024 15:20 --addr=VivoCity
The system silently parses 31/04/2024 as 30/04/2024 which could mislead the user into thinking that their appointment starts on the 30th of April instead of the 31st of May!
This behavior of our application was already mentioned and declared as a planned enhancement in our user guide.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
[ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue type
Team chose [`type.FeatureFlaw`]
Originally [`type.FunctionalityBug`]
- [ ] I disagree
**Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity
Team chose [`severity.Low`]
Originally [`severity.Medium`]
- [ ] I disagree
**Reason for disagreement:** [replace this with your explanation]
Currently, it has been documented that when provided an invalid date such as 31/02/2025 (February only has 28 days in a non-leap year), the system sets it to the nearest valid date instead of rejecting it.
I feel that a warning should also be given to reflect the system's action and decision. This is because the invalid date could have been a result of the user's mistake in typing in the month.
For instance, a user intends to schedule an appointment for a workshop from 31st May 2024 to 14th June 2024 but accidentally enters 04 instead of 05 resulting in:
sched 5 --title=Workshop --from=31/04/2024 15:00 --to=14/06/2024 15:20 --addr=VivoCity
when it should have beensched 5 --title=Workshop --from=31/05/2024 15:00 --to=14/06/2024 15:20 --addr=VivoCity
The system silently parses 31/04/2024 as 30/04/2024 which could mislead the user into thinking that their appointment starts on the 30th of April instead of the 31st of May!
Steps to reproduce:
sched 5 --title=Workshop --from=31/04/2024 15:00 --to=14/06/2024 15:20 --addr=VivoCity
Resultant output: