Team's Response

Hi there, thanks for the feedback. We have decided not to accept this issue as it is a class behaviour from java’s LocalDate class.

The date 17-04-0000 is actually invalid as such dates do not exist. Refer to https://en.wikipedia.org/wiki/Anno_Domini#No_year_zero:_start_and_end_of_a_century

LocalDate only throws a single error if there is a problem with parsing. Hence, it is too tedious and difficult to manually check each type of error arising from the parsing of date strings by ourselves. Examples of errors are wrong date format (YYYY-MM-DD) or invalid years (e.g 0000) Therefore, this bug report is out of scope for v1.4.

Refer to #507 and #2323 at here for more info

The 'Original' Bug

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

Incorrect error message for invalid date.

When "add n/Bob p/87632489 e/bob@email.com b/32-13-2020 a/bedok 123" is entered, an invalid date error message should appear. However, the error message thrown instead is a invalid date format error message.

Screenshot 2021-04-16 at 2.29.12 PM

_{[original: nus-cs2103-AY2021S2/pe-interim#2323] [original labels: severity.Low type.FunctionalityBug]}

Their Response to the 'Original' Bug

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

Hi there, thank you for your feedback. The team has reviewed this report and has decided that this is not a valid bug.

The date inputs are parsed using Java's LocalDate class. If the class is unable to parse the date string, the error will be caught and returned to the user with the error message above. There could be many reasons on why the parsing failed. The date format could be YYYY-MM-DD or out of range like having 32 in its days. The LocalDate class only returns a single error type if something went wrong.

Therefore, to have distinct error messages for each type of error. We have to manually check each date input string by ourselves. But, it is extremely tedious to do that and so we just relied on the LocalDate parser to notify us if there is any error.

Due to the difficulty and effort needed to catch each type of error, it is out of scope for v1.4.

Refer to #507 and #511 at here for more info

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: The duplicate gave an illegal date but my date should be legal by the means of their reasoning and should not have errored out.

:question: Issue response

Team chose [response.NotInScope]

[x] I disagree

Reason for disagreement: Unforutnately LocalDate does accept year 0000, in java 11. So the team has not tested LocalDate properly with their input.

Futhermore, instead of pointing to a definition in the wikipedia that they did not include in their UG, they should look at the limitations they gave the users.

It defines and upper bound but does not define a lower bound other then a format. The team should have tested the equivalence partitioning of their command or the LocalDate class and included a lower bound in the UG if they found the testing to be too tedious.

BenedictBCJJ / pe

Date not accepted despite following the format #6