Intervals with a backwards-pointing duration are returned in reverse order

[Matti Niemenmaa]

Intervals with a backwards-pointing duration are returned as a pair with the later datetime first:

>>> aniso8601.parse_interval('P1D/2001-01-01')
(datetime.date(2001, 1, 1), datetime.date(2000, 12, 31))

I would expect the later datetime to come last, so that P1D/2001-01-01 and 2000-12-31/P1D give the same result and the returned value is always of the form (start, end).

This is with aniso8601 1.1.0.

[Brandon Nielsen]

This is by design. Otherwise the user would have no way of knowing if the duration points 'forwards' or 'backwards' without parsing it themselves.

Since the parse result is a tuple, a sorted result can be achieved by using the sorted keyword, from the documentation:

Notice that the result of the above parse is not in order from earliest to latest. If sorted intervals are required, simply use the ‘sorted’ keyword as shown below:

>>> sorted(aniso8601.parse_interval('P1M/1981-04-05'))

[datetime.date(1981, 3, 6), datetime.date(1981, 4, 5)]

[Matti Niemenmaa]

Darn, sorry about that. It seemed unintuitive to me but I should've checked the docs first and your reasoning makes sense.

I do think this is a bit of a "gotcha" since only one of the possible syntaxes gives a different result and if one forgets about it, like I did, it's a nasty lurking bug. Perhaps most users are like me and want (begin, end) by default, and for those who care about the difference, it could be an unsorted=True parameter or different function entirely?

[Brandon Nielsen]

I agree with you, I dislike that the it behaves differently for one case only. I've also only found one use case that actually cares about whether a duration is going 'forwards' or 'backwards'. But it seems like if lots of people had an issue, someone else would have filed a bug by now.

I also don't like adding an option for something that can be worked around easily in base Python.

Sorry about breaking your code, I've found plenty of hidden issues caused by bad iso8601 parsing which is why I started this library, but this remains a wontfix unless more users comment here or on similar issues.