[* DateTimeV2] DateTimeRanges don't use context as basis for establishing limits

[NeilMacMullen]

First of all - GREAT library - I'm using this extensively in a suite of command line tools that need to input time ranges and it's so much more intuitive than forcing the user to guess the correct syntax for datetime parsing etc.

That said, I think Recognizers.Text.DateTime could do a slightly better job with 'ambiguous' ranges. For example, the input

2pm 1st jun 2000 until 2am on 2nd

Currently produces this resolution:

timex=(2000-06-01T14,XXXX-XX-02T02,PT157788H) type=datetimerange start=2000-06-01 14:00:00 end=2018-06-02 02:00:00

whereas the end is almost certainly better interpreted as being in the same year as the start. I do understand that this is ambiguous and there are contexts where a user may really intend that the end date here is relative to now but currently there is no way to provide a policy to assist with interpretation. Perhaps introducing the concept of a 'basis' date that defines the users expected context would be useful?

Alternatively it would be good to be able to understand "2pm 1st jun 2000 until 2am on the next day" This also currently provides an end date in 2018

Interestingly, this input does produce the expected output so there seems to be a bit of an inconsistency here.

2pm 1st jun 2000 until 15:00

timex=(2000-06-01T14,2000-06-01T15:00,PT1H) type=datetimerange start=2000-06-01 14:00:00 end=2000-06-01 15:00:00

[aitelint]

@tellarin, should we look into this one?

[tellarin]

@LionbridgeCSII, please take a stab at it after the newly opened issues. This will probably require bigger changes to solve in a more general way. But it would be great to at least estimate the effort. The resolution code should also start to be refactored into its own module, piece by piece. Currently there's a bunch of duplication and mixed concerns.