Auto-format search results without informing user

[NGXZS]

Description

Auto-format search results without informing user

Reproduction

Add item i11 as shown below search -e 29-02-2025..

Error Message

Actual

Expected

program to prompt user "no such date exist, searching from 28-02-2025 instead" etc as user may not know future dates don't exist

[nus-pe-script]

Team's Response

Duplicate of #1795 as fixing one fixes both.

The 'Original' Bug

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

Invalid expiry date

input an invalid expiry date for an inventory item but managed to add, item added with a different expiry date

---

_{[original: nus-cs2113-AY2324S2/pe-interim#1597] [original labels: type.FunctionalityBug severity.High]}

Their Response to the 'Original' Bug

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

This is an interesting catch. I was able to reproduce this bug using different dates, such as 31-02-2025 (which is resolved to 28-02-2025), or 31-06-2024 (which is resolved to 30-06-2024).

I have done a bit of research on this, and this appears to be an odd quirk of the java.time.format.DateTimeFormatter class.

• https://stackoverflow.com/questions/32823368/java-8-localdatetime-is-parsing-invalid-datetime
• https://stackoverflow.com/questions/29014225/what-is-the-difference-between-year-and-year-of-era

This was an oversight on my part, as I wasn't aware of the different types of year formatters that can be used.

I thus accept that this is a valid bug, however, I do not agree with the bug severity.

In most cases, invalid dates are appropriately handled by the application (i.e., if I were to pass in something like 30-30-2030, the application correctly recognizes that this is seriously invalid and will reject the user's input).

In this case, while the provided date is invalid, the resolved date is valid. The application does not crash or become unusable due to this bug, and hence a High severity is unjustified here.

Furthermore, I also believe that this issue does not hamper the user's ability to use the product. In such cases, if a user were to input a date like 31-04-2024, it is extremely likely that they were simply mistaken, with respect to the number of days in a month.

Assuming that they intended to input the last day of the month as the item's expiration date, our application will correctly resolve the date accordingly (to the correct date). No usability issues are created for the user, and to reiterate on my previous point, this is a rare occurrence. Thus, Medium severity is not justified as well.

Therefore, I believe, and accept, that this bug is of a Low severity.

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.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** The main problem specified by my bug report is "when the user inputs a non-existent date, program will **auto format it without informing** the user". Here, the **lack of notification** to the user is the `FeatureFlaw` (ie "not complete", as a **complete feature would inform** the user, then handle the date by auto-formatting it. See guidelines below:  I can see why the team and the duplicate term it as a `FunctionalityBug` as "it does not work as expected" (ie state whatever date the user input)  In this case, I feel both sides have equally valid points. As per the guidelines below, **both types can be accepted**: 

---