My argument for this is that it keeps the rules simple, and is flexible but still constrained.
Votes? And if you vote No/-1, a short reason please.
-1 because I think that date! and time! values should be normalized in a data exchange format. Though, specifying such rules would make the spec significantly more complex, but not doing it would just shift the burden onto the implementers, which might result in different interpretations. For the duration use-case, I am for using a different format than time!, maybe resulting in a new datatype.
(I am taking the perspective of people implementing REN in non-Rebol languages)
How does the above proposal make it harder for non-Redbol languages?
For duration, are you thinking something like "1h2m3s"? If so, that kind of leads to a general units notation.
One of my thought experiments, as you may know, was to reduce the total number of datatypes Ren understands, to help facilitate adoption. Hence the implied-string type in the current spec, which covers the idea of any-string! to some extent. I considered the same thing with the segmented number type, which could be generalized to cover tuple!, time!, and pair!/point!. The issue there is that I didn't think it would be good to say [number! sep number! ...] and try to fit in exceptions.
And I wish there were easy answers. We know that we can loosen restrictions later, but can't make things more stict. I think we can safely assume that the harder we make it to write a conforming parser, the more likely it is that people will take shortcuts. e.g., we specify 00-59 for seconds but parsers use [2 digit=] as a rule, like RFC3339.
Where is that nice clear line between syntax and semantics? How do we allow people to use Ren in ways that may not be clear to us right now, while disallowing things that make no sense at all?
Also, complexity is mitigated if we required hour, minute, and int part of seconds to be fixed at 2 digits, if we go down the stricter path.