I think it would be useful to allow milliseconds, and possibly microseconds. The use cases I see are sharing profiling information, debugging information and logs (of high volume systems) via REN.
Geomol
Hours should be allowed to be more than 23, right? It's not just for clock time values, but also for how much time until some event.
Arnold
Sure I work 40 hours a week, 180 in 4 weeks about 190 a month.. Our project is 200 hours estimated. Etcetera and so on.
that should be 160 in 4 weeks of course, but I declare 180 for sure. No 620 minimal ;-)
Gregg
Any fractional decimal amount should be allowed for seconds.
integer : [00-59] : [00-59 opt frac]
Gregg
I think my current spec, which uses [2 digit] for hours and minutes, was modeled on IETF RFCs where they do the same thing. REBOL's behavior is different for time values that are part of a date, than for pure time! values. It throws an error on date! values with non-sexagesimal clock time values (i.e. > 23:59:59). Assigning a time! to a date/time does a modulo 24:0:0 on it.
Gregg
So we effectively have time! and time-of-day!.
PeterWood
You could sat duration! and time!
Endo
Fraction for seconds is good to be compatible with SQL datetime values (MS SQL Server at least) Duration! is also a good idea. If we don't use it, then I vote for HH bigger than 24.
Gregg
But if duration! is also a valid time!, how do you know which it is?
1) We are representing data 2) We have to keep the rules simple
Q. Should Ren enforce rules about time!, or just define what a time! value looks like?
Gregg
There is also the question of attacks with crazy values. If we allow things like mixed signs, does it make implementations easier or harder to get right? Same for large values (overflow) if we don't restrict it to sexagesimal.
Gregg
I never thought time! would raise so many questions.
PeterWood
One way to distinguish between a time! and a duration would be that a time would need a timezone.
03:00 could be considered ambiguous as a time without a timezone. A duration is indpendent of timezone.
PeterWood
The counter argument would be a use case, where you wish to distrubute a time of day independent of timezone e.g the time of a nightly back up being 02:00
Geomol
time-of-day is a subset of a time! value. So defining time!, where hours can be > 23, and the format can cope with time-of-day. Is it up to the format the put restrictions in this case? Isn't it up to the user of the format to assure, hours <= 23, if it's a time-of-day value? And putting time from a date value in Rebol/Red/World/what-ever-language into REN will just work, and no checking is needed.
Gregg
Right. For example, JSON says what a number looks like but doesn't specify limits on number of digits.
The case of date-time values is a little tricker. Should Ren allow you to specify an invalid time of day? If so, behavior may vary by implementation (unless we provide guidelines). If not, the spec becomes more complex.
PeterWood
I feel that the REN standard should be specific and that a time associated with a date needs to be valid. Implementations may differ. After all, browsers have always rendered "invalid" HTML, libraries handle "invalid" XML and, to a lesser extent, libraries handle "invalid" JSON (even eval() can if some circumstances).
Gregg
Consider http://www.ietf.org/rfc/rfc3339.txt . The ABNF for hours is: time-hour = 2DIGIT ; 00-24 But also refs ISO8601 in 3339, where it says time-hour = 2DIGIT ; 00-23
The text says this: "Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion."
One of the things I want to do is provide a grammar for Ren, to bootstrap implementations and reduce confusion. Is it OK to have a simple informative grammar in the intro, which hides details, and a strict grammar for the real deal? Or is that "bait and switch" (luring people in with false advertising)?