Date range constructor automatically sorts start/end dates

[TristanJM]

DateRanges should have start date before the end date, this is now automatically corrected in the constructor.

Should a user need a reverse range, they can easily change their application logic to remember that start/end is the opposite.

Closes #106

[gf3]

👍 lgtm, don't forget to update the CHANGELOG

[neverendingqs]

This doesn't seem safe to me (e.g. developer calling this makes a typo).

Double-check: have we already considered throwing an error instead?

[TristanJM]

Thanks for discussing 😃

IMO the library should provide the core time functionality, and the user can easily change their application logic if they're expecting a reversed time range. We classify it as a period between two points in time, rather than a directional period.

Throwing an error isn't ideal because most of the time, the functions on a range behave identically regardless of the start or end. I would think that it's far more inconvenient to require application start/end checks or error handling when they likely aren't requiring reverse time ranges? But I see the issue (if it's not documented clearly) of users not understanding what's happening.

@gf3 do you think it's better to throw error or is it unnecessary?