Allow times to be 24:00

[jotaen]

Say, if you work until midnight, you can’t say: 18:00-24:00, which would be logical actually. The spec doesn’t say anything about it.

I can’t remember the reason why I didn’t allow the time to be 24:00, I think it was just because the underlying library I use behaves like this. (See time.go, but I have an explicit test for this.)

0:00-24:00 should be a total of 24h.

[jotaen]

Writing 24:00 could just be like an alias for 0:00>.

24:00> obviously wouldn’t work, though, since >> is not allowed. But I guess that might be alright.

[vladdeSV]

For info, RFC 3339 does not allow 24:00.

[jotaen]

Good point about the RFC. I think strictly speaking, time rolls over to the next day after 23:59:59.9999999…, so if one says “today, 24:00 o’clock” they really mean “tomorrow 0:00 o’clock”.

I suppose 24:00 shouldn’t be allowed as value by the underlying Time datastructure. However, when constructing a new time object, we could interpret it such as:

• <24:00 → 0:00
• 24:00 → 0:00>

That way, the user can use this notation in the file (for convenience), but internally we still work with the “correct” representation.

24:00 would be the only exception in that regard, so 24:01 still doesn’t make any sense.

[jotaen]

It would be relatively straightforward to support this: #131

I think it would be best to take note of these two special cases in the Spec, though, just for the sake of completeness.