AltME: Ren - Data Exchange Format

Messages

Gregg
We'll make a decision in T minus 0:0:5..0:0:4..0:0:3..
DocKimbel
:-)
Rebolek
I agree with limited specs.
Gregg
One of the other nice things about limiting it is that we can later loosen the restrictions if a strong argument can be made to do so.
DocKimbel
If you want to have a wide support for Ren in non-Rebol languages, the smaller the specification, the easier to support it.
Rebolek
Exactly.
Gregg
Agreed, but more limiting, in this case, doesn't mean a smaller spec.
i.e., having to specify sexagesimal rules.
Gregg
What about leap seconds (23:59:60)?
Again, it could be extended later.
DocKimbel
I wouldn't allow it either. Only stricly valid time values.
Rebolek
I vote for later. When someone is going to use Ren for running an atomclock, we can extend the specs ;)
Gregg
Agreed.
PeterWood
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!

Last message posted 408 weeks ago.