Open ltzehan opened 1 year ago
In a 24hour clock, 24:00 and 00:00 are equivalent, date time parsing handles this appropriate and correctly.
Team chose [response.Rejected
]
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.
Using the 24-hour clock, it is unclear how
24:00
should be parsed, but it appears that SNIFF automatically converts this to00: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.