soc-pe-bot
commented
7 months ago Team's Response
Hi! Thank you for your response. In our UG, the restriction to the time parameter is given as follows,
The team believes this is an acceptable system behaviour, as the input parameter is of this universal time format and should have been recognised as a valid input.
On the other hand, the team also understands the concern of the tester that the HHMM value of 2400 should be disregarded since it could confuse users from the 0000 value the next day. However, we feel that this should instead be a restriction that is imposed in terms of display rather than input, to cater to the possibility that some users may prefer this form of representation. Hence, this boundary case is still regarded as an acceptable input and treated equivalently to the later expression. Rest assured, any time after this value which takes the same form of representation (HHMM values after 2400) is rejected.
To further add on, as seen from the example below, this issue is actually taken care of in terms of our system display to reduce confusion.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
When filtering for a transaction I can filter the time as 2400 which should be an invalid time format.