nus-se-bot
commented
3 years ago Team's Response
To parse the date and time, we are currently using java's LocalDateTime.parse. It appears that any date input that is less than 32 (>=32 will still result in an error as expected) and more than 0 would be accepted by the parser. However, if the input date exceeds the last day of the input month, it automatically sets it to the last possible date for the month. An example would be the month of October, where the last day is the 30th. If 31-10-20 12:00 is parsed, it automatically is set to the 30th instead of throwing an error.
For the above case, as 30th February is an invalid date, the Java LocalDateTime parser automatically parsed it to the last date possible for the month (29th for the month of February), hence was registered as 29th Feb on the system despite the input being 2020-30-02.
Unfortunatedly there is no easy way to fix this on our part as parsing is based on a method in the pre-existing LocalDateTime class which causes this error.
We regret that this issue was not mentioned in the user guide. Bug type has been changed to documentation bug as a result.
Downgraded to low as this is a bug that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
Items for the Tester to Verify
:question: Issue type
Team chose [type.DocumentationBug]
Originally [type.FunctionalityBug]
- [x] I disagree
Reason for disagreement: This problem can be solved by "withResolverStyle" method for LocalDateTime easily. Therefore, I would consider this bug to be functionality bug rather than documentation bug.
There are three modes to choose for your LocalDateTime. You should include which mode your product adopts in the UG as well.
As for the severity, it can be quite subjective. As there is a "lenient mode" provided in LocalDateTime, some user likes to enter date directly by adding the number of day e.g. (Today is 2020-11-19, I wish a certain event to be held in 60 days, then I can put 2020-11-79 instead of calculating the date by myself.) I think few people would like to use it this way, therefore, I accept the downgrade.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
Build Number: Version1.4 Reported By: Eddy/Chu Yi-Ting Reported On: 2020/11/13 Environment: MacOS version 10.15.7 Reason: Legitimate user behavior not handled Description: when adding invalid date time, the system does not reply with error, nor does the user guide specify the behavior for this. There can be multiple possible ways to handle the date. Can refer to the Java LocalDateTime api, but would be better if it is specified in the user guide.
Expected Result:
Actual Result:
Steps To Reproduce: