Ambiguous parsing of HH:MM

[ltzehan]

Using the 24-hour clock, it is unclear how 24:00 should be parsed, but it appears that SNIFF automatically converts this to 00:00 for the same date instead of warning the user of an ambiguous input.

Since this is an edge case, it is unlikely that all users will be affected, but this is a flaw in the parsing logic.

Example:

The second appointment clashes with the first due to the way the time is being parsed.

[nus-se-bot]

Team's Response

In a 24hour clock, 24:00 and 00:00 are equivalent, date time parsing handles this appropriate and correctly.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: It is true that 2400 and 0000 both refer to midnight, but there is a nuance when dates are involved. Most applications opt to avoid including 2400 as a time format because it poses more confusion than is helpful (this is a very common issue! Ref.: ISO 8601, see Section 5.7).

In any case, since this behaviour is not specified in the UG, then it is not unreasonable for the user to expect this to follow standard behaviour, with 2400 specifically referring to the end of a day and 0000 referring to the beginning of a day. When the dates are included, this would mean that 2023-01-01 2400 and 2023-01-02 0000 are equivalent. However, what is observed is that the two appointments (which by this standard are actually 24 hours apart), are being recognized as the exact same time.

At the very least, the UG should explicitly mention this non-conformance with the standard.

---