I know this is a long discussion but, it's such an important element, I think it's worth it.
- I don't like the ISO8601/iCal/Go format for durations. e.g., "P3Y6M4DT12H30M5S" - I DO want a dialect or lexical that lets us express units, but now is not the time, as Doc says. - I think we should support large relative date-time values.
Also, I should note that I use Doc's scheduler library, and extended it a bit. The period/interval dialect there works well in that context.
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.
"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?
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.
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?
Does anyone object to this group being [web public]?
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.
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.