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.
In Ren goals, there is: "Be easy for humans to read and write". If you allow to write date/times as implicit computations, like: 05-31-2015/100:32:06, it would be equivalent to allow writing integers as, e.g., 10 * 8 + 6 - 4 * 7 instead of 574. Ren is a data exchange format, it's not the Rebol console. :-)
I am not fond of having string format covers any-string!. IMHO, it reduces the value of Ren compared to other formats. Removing the quotes for tags, email, url,... is one of the great things of the Rebol format, I think Ren should follow the same path. If you want to compete with JSON wrt the spec size and complexity, you risk ending up crippling Ren, and reducing its added value.
Sorry for some bad grammar in my above posts, it was written before my morning coffee. :-)
"Storing in memory each time component as 32-bit values is obviously a waste of space, so this is not satisfying."
This, I would say, is not Ren's concern, and somewhat akin to saying ints should be 16 bits.
But I think we're largely on the same page otherwise. :-)
I started a Ren parser, and if we're OK saying that the time part of a date, and timezone as well, are limited, then all we have to fight about is standalone time values (relative time). Because if I can only say 23:59:59, maximum, not only do I lose meaning, but I'm limiting the relative range I can talk about. Strictly speaking, I can't even say 24:00, right?.
This does add some complexity, though it's not bad as long as we require a fixed number of digits in each segment.
Note that my implied-string is separate from a quoted or braced string. No quotes. The one thing I don't cover yet is tags, which is tougher. It's pending question about whether they can be considered just another kind of string, and can we also present parens as just another list synatx along with square brackets. I was thinking of leaving them out of v1, having a page of proposals, and adding them later.
"This, I would say, is not Ren's concern, and somewhat akin to saying ints should be 16 bits."
Well, I understand your perspective, but you should realize that even R2 and R3 could not support Ren as-is if you stick to 32-bit time components.
A special case could be made for 24:00 value, though, I think that it is not worse it. If you want to represent just hours, you can use integers for that.
worse => worth
Timezones are another tricky area. I believe the range of timezones is -12:00 to + 14:00. Most timezone are either 0 minutes or 30 minutes. However, there is Chatham Islands (New Zealand) at +12"45, Eucla (Australia) +8:45, Nepal +5:45. None at 15 minutes past the hour though.
There are always going to be limits in implementations, no doubt. But R2 loads 99999:99999999:999.999 just fine. R2 also does some crazy things with signed times and overflow, but that hasn't stopped it from being useful 99.9999999% of the time(s). ;-)
Also, R3 gives a different result than R2 for the above time value.
A compromise would be to set a limit that could be represented in most langs with reasonable efficiency. And look at it the other way. How many systems use epoch seconds, ms, or 100 ns as time units? We need to be able to represent those, correct? If not, you end up with integers, as you say, which provide no meaning. We effectively cripple time.
I don't worry that people will generate huge values from other systems, because those have their own limits as well, so the chances of someone generating a time like the above is virtually nil. My concern is security and opening doors for overflow attacks and such.
Again, I'm OK with limits for absolute time values, as in date-time. Timezones are an issue, which are a constrained relative time, and I'm good with limiting those as well. Right now my parse rules allow any hour 00-23, which we can address limits of separately if we want.
I thought there was something at a 0:15 offset, but it's easy to remove.
In order to allow large relative times to be represented, we either need to allow times to contain large segment values and/or extend the notion of time to include duration as well, with a new notation.
Do not limit timezone at 15 minutes. Timezones should have at least 1 minute resolution.
Even though they aren't recognized as valid? Noting that I agree with you :-), why so?
"Valid" meaning "used in the world today".
The reason I'm OK with the 0:15 limitation in v1 is that we can later relax the constraint without breaking data. In general, I want to let people express their data, even if it may not make sense to us right now. We say what a type of value looks like, but impose few semantic restrictions.
Timezones are crazy stuff, there were not quarter hour based timezones in the past and there's no reason to not expect them in the future.