I haven't had any today...
From: Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] On Behalf Of Per Bothner
Sent: Monday, November 08, 2010 12:45 PM
To: [log in to unmask]
Subject: Re: [DATETIME] Interval sign: "/"
On 11/08/2010 07:05 AM, Denenberg, Ray wrote:
> Well I join you in regretting that ISO chose "/". However, If we were
> to adopt a sequence of dots, or for that matter any convention other
> than "/", it would mean abandoning the premise of this work, that any
> feature prescribed, if it is a feature supported by ISO 8601, will be
> prescribed in a manner compatible with ISO 8601. My position on that
> is that there would need to be overwhelming sentiment to do that.
I agree parsimony argues for "if it is a feature supported by ISO 8601, will be prescribed in a manner compatible with ISO 8601", but I don't violating that rule breaks much. To parse an EDTF specifier one needs a EDTF-aware processor. and a 8601 processor won't cut it. The only thing using "/" might enable is that "converting" a 8601 string to an EDTF would be a no-op. However, even that would not be true, since EDTF "selects relevant/necessary features of 8601, discarding unnecessary features."
I noted an inconsistency for "Uncertain, but known to be one of a set."
One of the years 1667, 1668, 1670, 1671, 1672 In this context, we're using hyphens for a set.
I recommend just using ".." for an interval, so the above would be:
What about when "The endpoint of an interval is another interval"?
One option is to use parentheses - after all we already use parentheses for grouping of questionable dates, which this is, so instead of:
Alternatively, we can use square brackets, since presumably an "internals of intervals" really means that the endpoint is "Uncertain, but known to be one of a set". Thus:
On a related note, we can possibly get rid of the "Before/after indicator".
I think this would be more readable:
If you need "before" rather than "before or equal" you could do:
When it comes it handling 8601-style "/", we have so choices:
(1) Not allow it. A 8601-style internal has to be explicitly
converted before being passed to an EDTF processor.
(2) Allow, but discourage "/" as a synonym for "..". An EDTF processor must allow "/" in input. On output it is recommended (but not required) for it to produce ".." and avoid "/".
(3) Make handling of "/" optional, like in a profile.
I think (3) would causes more trouble than it is worth, so I would recommend (1) or (2). Specifically (1) for simplicity.
[log in to unmask] http://per.bothner.com/