nus-pe-bot
commented
5 months ago Team's Response
Thank you for bringing this to our attention. After reviewing the User Guide, we agree that there might be some confusion regarding how leap years and invalid date inputs are handled. As stated in the User Guide, our system adheres to the ISO-8601 calendar system for leap year calculations. This means that providing a leap day on a non-leap year returns the last valid day of that month. While your observation about adding Feb 31 or Apr 31 is valid, our system is designed to interpret invalid dates by returning the closest valid date according to the specified month. We recognise that this behaviour might not have been clearly articulated in the documentation. Moving forward, we will amend the User Guide to include a more explicit explanation under the title "Handling leap years and invalid date inputs" to better clarify this functionality. Thank you for bringing this to our attention, and we apologise for any confusion it may have caused.
Items for the Tester to Verify
:question: Issue type
Team chose [type.DocumentationBug]
Originally [type.FeatureFlaw]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
I thought typing in a leap year date in a non leap year refers to adding date Feb 29 to year 2023 for example, exclusively. However, I tried adding Feb 31 to year 2022, which is not supposed to exist in any sense, but the feature still interprets the date as the closest valid date.
add cn/Google n/ABCD p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 tt/023120221400 i/remote work s/5000 pl/Java t/friends t/referral pri/2
The result is below.
Also I tried adding Apr 31 which is also not supposed to exist at all, regardless of the definition of leap year.
add cn/Google n/DEFG p/98765432 e/johnd@example.com a/311,Clementi Ave 2, #02-25 tt/310420221400 i/remote work s/5000 pl/Java t/friends t/referral pri/2
Result is below.
A quick fix might be to note that in the UG.