Interval toString/parse support for unbounded intervals

[haraldk]

I'm currently working on a project that uses a lot of unbounded intervals (open ended). Seeing a lot of unbounded intervals written as closed intervals with end dates far into the future is somewhat confusing and unnecessary hard to read.

I'm proposing adding support for open intervals in Interval.toString() and Interval.parse() methods, using the ".." notation for open ended start/end in the string representation. These will be replaced Instant.MIN/Instant.MAX for start and end respectively during parsing, to keep the current behavior otherwise unchanged.

As an example:

Instead of 2021-04-22T11:19:07.422304Z/+1000000000-12-31T23:59:59.999999999Z
we use 2021-04-22T11:19:07.422304Z/..

I'm not 100% if this ".." notation is part of or some extension of ISO8601, or just a de facto "standard". I'm open for using different notation, if ISO8601 (or extension) says so. 😀
My main concern is readability and a good consistent way to serialize/deserialize unbounded intervals across different systems.

If this sounds like a good idea, I can go ahead and create a PR if you like.

[perceptron8]

You may like to check #100.

[perceptron8]

... or at least #100 (comment) and #100 (comment).

[haraldk]

@perceptron8
Thanks! Those comments seems to be spot on. Although it's a bit hard to see what the conclusion is, given its status as fixed/closed (but the code is not there..?). The full #100 issue seems far more complex than what I'm proposing. 😀

I also filed #184, which is of course related.

[jodastephen]

I think this change could be added to a v2 branch. It would be a step forward for unbounded intervals.