AltME: Ren - Time & Duration

Messages

Gregg
Rebol's solution to relative time values is to use two datatypes: time!, allowing large non-sexagesimal values and normalizing them on load, and integer! which is the number of days between two dates. This maps reasonably well to the .NET and Python approaches, and makes sense if we want unambiguous offset values (because month and year lengths vary). That doesn't mean we can't support separate YMD values in a lexical format, just that we need to say what they mean to Ren.
I shouldn't say non-sexa* values, as it does treat them as such. I mean overflow values.
Gregg
"we need to say what they mean to Ren." By this, I mean is 4 years the same as 1460 days, 1461 days, or neither and the math is up to you?
Gregg
Absolute and relative date-time informative rules: http://ren-data.org#abs-date-time
Basically, constrain absolute values, don't allow timezone on relative values, and require a sign on relative date and date-time values to distinguish them from absolute. Relative time values do NOT require a sign, with the expectation that time-of-day would not be an independent value type.
Gregg
Is this getting us closer or further away? It doesn't answer constraint questions, like a 4 digit limit on abs years, large values in relative parts, or minimizing overhead. Does it need to?

Gregg
Does anyone object to this group being [web public]?
Andreas
web-public: Fine with me.
The absolute / relative date/time proposal up on ren-data.org looks quite good. A few thoughts after first digesting it for a bit:
Standalone times as relative times: +1
Basic constraints for month and day value ranges in date and time-of-day/seconds: +1
Standalone relative dates don't strike me as something particularly worthy of providing, at first glance.
I also think that the forced sign looks rather awkward for negative rel-dates: -1-1-1, -10-0-1. Further, I think that date arithmetic with relative dates may be _really_ awkward.
So I'd suggest limiting any-data-time to just abs-date-time or abs-date or rel-time, for starters.

Gregg
Thanks Andreas! Good feedback. I agree that negative rel-dates aren't pretty. When I wrote examples for my test parser, I used 4 digits for all years, which made them less ugly (-0000-01-00). We could easily require a minimum of 4 digits. Still not perfect, but perhaps better.
I also agree that date math is tricky (all around), but Ren doesn't have to do the math. :-) For me, it's a question of "how else do we do it?" if relative dates are useful?
Tough call, as I think there *is* value in relative dates. Some of that value comes from them being imprecise, which conveys meaning as humans sometimes do.
DocKimbel
No objection.
Rebolek
no problem
Arnold
ok here
Gregg
Done.

Last message posted 128 weeks ago.