Ticket UUID: | aee9f2b916afd9765631a3b74383248ddbfa4e09 | |||
Title: | clock scan -validate, ISO-8601, 24:00 | |||
Type: | Bug | Version: | 8.7 | |
Submitter: | jan.nijtmans | Created on: | 2024-11-20 09:37:22 | |
Subsystem: | 16. Commands A-H | Assigned To: | jan.nijtmans | |
Priority: | 5 Medium | Severity: | Minor | |
Status: | Closed | Last Modified: | 2024-11-20 19:39:59 | |
Resolution: | Fixed | Closed By: | jan.nijtmans | |
Closed on: | 2024-11-20 19:39:59 | |||
Description: |
When working on the leap-seconds, two more small deviations: % clock scan "24:00" unable to convert input string: invalid time (hour) % clock scan "00:00 am" 1732057200 Hour "24:00" should be interpreted as "00:00" next day. This is only allowed when minutes and seconds are zero. When using am/pm, the 12-hours clock runs from 1 to 12, so "00" should be invalid. But ... since in Japan it is common to use a 0-11 hour clock, I think we should leave this as is. Just mentioning this for completeness. Since those two are fully separate from leap-seconds handling, let's handle them separately. | |||
User Comments: |
jan.nijtmans added on 2024-11-20 19:39:59:
[9e101107|fix] now merged to trunk. sebres added on 2024-11-20 16:18:10: Agree about "00:00 am" or "00:00 pm" (and it doesn't bother at all). However, I don't think that "24:00 am" or "24:00 pm" (with meridian) are correct values (in sense of relation to meridian), so [bf0e4fe924f77516] looks a bit strange to me (regardless validity mode)... Although, probably matter of taste either. And "24:00" (without meridian) is already working properly (excepting in validity mode). So my guess, we need to fix only this. |