nus-pe-bot
commented
1 year ago Team's Response
This stems from the same issue since the parsing is handled by the same library.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Unexpected time to autofill
Entering the command "ap n/test6 d/15-04-2023" gives me the following output:
The program has added a deadline timing of 3am which does not make sense to me as the user. Even if a time was to be displayed, I would expect midnight to be the default time.
[original: nus-cs2103-AY2223S2/pe-interim#1142] [original labels: severity.Low type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
The current expected behaviour is that the app parses all deadline inputs into a date-time output due to the library used to parse natural language/date formats. If no time is provided by the user, the current time is taken as the time to use.
Due to the usage of a library, it would take a lot more effort to remove the time of the output if no time is provided by the user. The user can also edit the deadline to have a 12am time if needed.
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)
- [x] I disagree
Reason for disagreement: This issue is not a duplicate of the original bug. The original bug is about the unexpected default timing when no time is provided. This bug is about how the application handles ambiguous dates that can be interpreted differently based on the format (dd-mm-yyyy vs mm-dd-yyyy)
## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** This bug should not be NotInScope. Accurate date parsing should not be unprioritized in a project management app
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** This is not an incomplete or missing feature but an unexpected behavior with their existing feature that they claim to have. (Storing of date and time for deadlines)
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** This inaccurate date parsing affects the first 12 days of every month in the year. This means that project deadlines that fall on more than one third of the year will be handled ambiguously by their app. Low severity states that it only occurs in rare situations however I believe one third of a year is not rare. I believe most users will encounter this bug and having the month and day of a deadline swapped is a major bug that would affect normal usage, thus justifying the high severity.
Entering the command 'ap n/test4 d/15-04-2023' creates the project as shown below:
However, entering the command 'ap n/test5 d/11-04-2023' gives me a project due in November:
The inconsistency of the date formats is quite a severe bug as it would greatly affect a user's management of projects and their deadlines. I classified this bug as High severity as it makes the deadline part of a project almost unusable as the user cannot trust the program to save the correct deadline.