AltME: Ren - Time & Duration

Messages

Gregg
New group for focused chat about time/duration formats in Ren.
Gregg
Gregg Proposed:
# Use cases
- standalone time (point in time)
- standalone time (duration)
- part of date-time (time of day)
- timezone (offset from UTC)
#Proposed rules
    time
        hours-minutes opt seconds
    hours-minutes
        opt sign  uint : uint
    seconds
        : uint  opt frac
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.
Doc Responded:
-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)
Gregg
How does the above proposal make it harder for non-Redbol languages?
Gregg
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.
Gregg
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.
Gregg
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?
Gregg
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.
Gregg
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?
Arnold
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)

Last message posted 459 weeks ago.