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.
And do we favor an informative spec with the appearance of simplicity over a normative spec that leverages existing rules. e.g., do we say a time is the same whether standalone, part of a date, or as a date timzone, or each has its own rules?
As I stated earlier, there could be more time systems possible, with a semi-serious hint to the Mars One expedition that REN should be able to handle. The thing is in interfacing sometimes there is additional information that is not in the format itself. Your example of the seconds 0-59 (or 00-59) and shortcutting quick test of that testing on 1 or 2 digits from 0 to 9. So the question is does REN need to force all information in a certain specific format? Or should it be less strict. (I feel like I said the same as your last comment now, in other words)
Other popular langs (JS, Java, .NET, Go, Python, Ruby) distinguish between an instant in time (datetime) and duration (period/timespan/timedelta) and, as you might imagine, there is no consensus on how things work.
An instant in time is absolute, a duration is relative.
If you use DIFFERENCE on dates in REBOL you get a time! value. If you use SUBTRACT, you get a number of days. Given two dates, 1 day apart, you respectively get 24:00 and 1. Both are relative but the latter loses information. Fully qualified, if we didn't have separate date! and time! values, they could be viewed as 0000-00-00/24:00:00 or 0000-00-01/00:00:00.
REBOL doesn't allow literal dates with a month or day of 00. Dates are absolute, and standalone time values are relative. The timezone part of a date is also relative but limited to absolute Earth-day hour values (except that REBOL does a modulo 32:00 thing with it). Relative vs absolute in REBOL is implicit.
Do we need to explicitly distinguish between relative and absolute date-times in Ren?
If so, Doc is right that we should limit absolute time part values, and that we need a new notation for relative times (e.g., yyyy:mm:dd/hh:mm:ss.s, yyyy-mm-dd+hh:mm:ss.s, etc.), which still doesn't solve the Mars problem. Maybe John (Geomol) will weigh in with astronomical thoughts on that. :)
Let's simplify the problems to solve to Earth time only, once men on Mars will be a reality, we can eventually try to push NASA to use Ren. ;-)
"How does the above proposal make it harder for non-Redbol languages?"
Because you need to make some assumptions about how to process the Ren data, the spec being too fuzzy. If you take this valid Ren time: 987:654:321, first, it fails to fit into the Ren-as-human-readable-format goal, then you need to store that into memory. Some Ren client developers might make the (a priori obvious) choice to use 8-bit slots to fit hour, minutes and seconds. In such case, they need to do some calculations to make it fit, which, in this example case, will result in an overflow for hours, and the spec does not say anything about what to do with that. Storing in memory each time component as 32-bit values is obviously a waste of space, so this is not satisfying. Moreover, some languages might already have some time supporting libraries which would not fit the choice made in Ren (because Ren would not stick to the standard human time format).
If we want Ren to be for humans, we should stick with formats humans can read and make sense of.
That said, limiting values to 2 digits + adding a mention in the spec that integers should be limited to respectively 24, 59, 59 would already be a big improvement IMHO.
"For duration, are you thinking something like "1h2m3s"? If so, that kind of leads to a general units notation."
Exactly yes, but even if I would be very glad to have a unit! datatype, it's a too big design work to open it now. I would stick to an ad-hoc literal format for durations in the form of _c_y_h_m_s to begin with. Given that we use a lot of sub-second durations in computing, it could also include _ms_us_ns. But this is a wider than Ren topic, I am thinking about a duration! type for Red since a while, but didn't have time to design it yet. Also, as you point out rightly, I would need to also consider a more general unit! datatype.