Incorrect handling of deadline in edit feature

[hweinian]

Overall description

There are several bugs that are not being handled in the edit feature. this makes the Deadline tag rather unusable to users as there are several bug. With so much bugs in the deadline, user may not even know if the deadline added is of the intended action.

Bug 1:

Description

When I edit the first index with the date 01-01-0000, it adds the date as year 2000 even though the year is 0000. As a user, there could have been a typo and the app would still accept it

Additionally

Steps to reproduce:

1. edit 1 d/01-01-0000

Screenshot

After entering the command: edit 1 d/01-01-0000

Bug 2:

Description

When I have added a date with trailing zeros, it apparently got accepted which I believe is not an intended feature of the app as stated in the user guide. The screenshot may be extreme, but even with 1 extra zero, it still accept it.

It works the same for 011-010-2000

Screenshot

Bug 3:

Description

Able to add dates like 010-010-010 which will save the date 10 october, 2010. As mentioned in DG, this input should be invalid and should show an error message

Screenshot

[soc-se-bot]

Team's Response

First of all, you are not meant to report more than one bug in a single report but thankfully your bugs seem to be duplicates anyways and can be addressed in one go.

Adding trailing zeros to a number does not change its value (so 0000 is equal to 0, 000000000000 is also equal to 0, and 010 is equal to 10)

In each of your bugs, the numbers provided do indeed fit the constraints: 0 and 10 are both 2-digit numbers within the range 0-99, and hence will be accepted by our application. This was for convenience, so a user can enter a shortened year (like entering 25 to indicate 2025, or 8 to indicate 2008).

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement:

Thank you for the response. I understand I am not meant to report more than one bug at a time, but as you did not choose which bug you would like to refute against, I will be explaining from the standpoint of bug#2 to make it easier for the moderator.

Adding trailing zeros to a number does indeed not change an integer value. However, it is indeed incorrect based on the format as stated in your user guide. Thus, accepting the value 010-010-2000, goes against the date format of dd-mm-yyyy. The format ‘dd’ from dd-mm-yyyy means it requires 2 digit to represent the date, ‘mm’ from dd-mm-yyyy means it requires 2 digit to represent the month, and ‘yyyy’ means it requires 4 digits to represent the month. So the value 01-01-2000 is not the same as 1-1-2000 as ‘1’ only represent 1 digit and not 2 based on the format.

If you were to assume that each number is not affected by trailing zeros, i.e. 0000 is equivalent to 0, this should be explicitly stated in the user guide as dates normally account for trailing zeros. Information such as This was for convenience, so a user can enter a shortened year (like entering 25 to indicate 2025, or 8 to indicate 2008). stated in your dev response, should also be indicated in your user guide on how the dates work. Your examples do show what your response is saying, but without your response, I would not know why your example works in such a manner.

Example of an improved guide:

1. Any valid date must be in the format dd-mm-yyyy (e.g. 28-02-2000 is a valid date). Note that dd, mm, yyyy can be of varying length, refer to point 3.
2. Dashes (-), Slashes (/), underscores (_), and vertical bars (|) can be used as delimiters.
3. The term dd, mm, and yyyy in the date format can be of varying digit length. E.g. 01-01-2025 is the same as 1-01-2025 is the same as 01-1-2025is the same as 01-01-25.
4. All years are defaulted as the year 2000 if not specified. E.g. 01-01-25 is the same as 01-01-2025.
5. Adding trailing zeros to dd, mm, or yyyy does not change its value. E.g. 010-010-010 is the same as 10-10-2010.
6. 3-digit years between 100-999 are considered invalid. E.g. 01-01-100 is invalid.

Conclusion

Overall, there seems to be a misunderstanding that occurred. The deadline in the user guide is defined with its own set of rules like how dd is of varying length and how trailing zeros does not change the value. The lack of explanation cause reader to make assumptions and guess on what the feature does. I would still believe that this is a severity.Medium as it would be hard to understand the user guide with missing information and ambiguous text. Users are still able to use the product if they manage to figure out the constraints. It will be of documentation.Bug as the explanation of your set of rules could be more explicitly explained by including more examples and explanation to guide user on how the deadline field works, instead of refraining information and only to be informed through dev response.

---