jonahtwl / pe

0 stars 0 forks source link

30th February date #2

Open jonahtwl opened 3 years ago

jonahtwl commented 3 years ago

image.png

30th February should be rejected. Likely due to the use of the same parser as my team which did not handle the 30th Feb illegal date, instead it auto converts to 28th Feb.

Should a user accidentally type 30th Feb (02) instead of 30th Mar (03) due to fat fingers sometimes like myself, it may pose a huge issue should they want to find something expiring but it is not actually expiring.

nus-pe-bot commented 3 years ago

Team's Response

No response provided.

The 'Original' Bug

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

invalid expiry date is automatically corrected?

image.png

When I add a food with 30-02-2029 as the expiry date, I expect a feedback on invalid date to be given since Feb does not have 30 days. However, the expiry date automatically changed to 28-02-2029 without informing the user that the date was automatically changed.

I appreciate the auto correct feature (if that is your intention), but the program should inform the user that the date is auto-corrected from xxx to xxx to avoid confusion, or simply reject the input.


[original: nus-cs2113-AY2021S2/pe-interim#199] [original labels: severity.Low type.FunctionalityBug]

Their Response to the 'Original' Bug

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

DateTime import automatically changes the date.

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)

Reason for disagreement: [replace this with your explanation]


:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

Reason for disagreement: Automatic changing is not the thing the user would want to see... let's say a user is keying in multiple items and want to do it quickly, having this issue, the user will have to... 1. remove the item... 2. add the item back again 3. if he/she accidentally keys in the same issue as previously, has to repeat from step 1.

And this problem is medium as, 30th Jan, 30th Feb and 30th Mar is just 1 key away from each other, and this is an issue in the Date Parser API (I am assuming you used the same one as my team) which is a known problem, so brushing it off and saying automatically changing is actually not a reasonable response as you did not do your due diligence in checking the API before using it.

It's the same problem as saying, i keyed in 32nd Jan and expecting the parser to convert to 31st Jan which does not make sense at all.

The severity should stay as medium as this is a huge issue when I am trying to find my expiry dates and when it concerns food.