search

Dethada / pe

0 stars 0 forks source link

Invalid Date Time value successfully parsed #2

Open Dethada opened 3 months ago

Dethada commented 3 months ago

Bug Description

310420251400 which translates to 31-04-2025 14:00 is not a valid date time and not leap year or leap day related, however providing it as a date time input results in 30-04-2025 14:00 being the parsed value.

Steps to Reproduce

Expected Behavior

The command should fail due to invalid date time provided.

Screenshots

image.png

nus-pe-bot commented 2 months ago

Team's Response

Thank you for raising this issue. While we acknowledge that this may cause inconvenience to some users, addressing this particular issue is currently not within our scope due to existing project priorities and resource constraints and we have mentioned how we handle leap dates in the UG. Our team is currently focused on addressing critical bugs and implementing essential features to enhance user experience. However, we have noted your feedback and will consider it for future updates to handle leap dates better. Thank you for your understanding.

image.png

The 'Original' Bug

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

Incorrect handling of leap years

Setting the /tt field to invalid leap years still create a new an interview time, but at the incorrect time.

For example, the following command:

add cn/Google n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 tt/290221002359 i/Birthday: 12 May 2001 s/5000 pl/Java t/friends t/owesMoney pri/2

Incorrectly determines 29 Feb 2100 as a valid date, instead choosing to depict it as occurring the previous day, as seen below:

image.png

[original: nus-cs2103-AY2324S2/pe-interim#187] [original labels: type.FunctionalityBug severity.Low]

Their Response to the 'Original' Bug

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

Already stated in UG

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: In my bug report I specifically mentioned that the date time I am testing (31-04-2025 14:00) is not a valid date time and not leap year or leap day related. The 'Original' bug however is specifically talking about leap year.

## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** This bug can cause serious problems for the user if not rectified, take for example if the user was sent an invalid interview date by the company due to human error (`31-04-2025`) and he keys it into the application and does not think much of it as the application did not throw any errors. The actual day that the company wants to do the interview is `1-05-2025` if the user relied on the application's record of the meeting date time, the user would have gone for interview on the wrong day. Therefore, this bug should be fixed with high priority.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** > type.FunctionalityBug: A functionality does not work as specified/expected. > > type.FeatureFlaw: Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage... This bug report is about the date time parsing not working as expected, therefore it is not a feature flaw.