Today at work I was looking at some older code and saw some DateTime comparisons and thought to myself that there should be really better ways to compare DateTime, Date and Time with each other.
Generally the things I saw the most where the following cases:
is a before b?
is a after b?
is a between b and c?
My initial idea was that the module could use some functions like DateTime.before?(a, b), DateTime.after?(a, b) and DateTime.between?(a, b, c), but quickly realized that it would be pretty easy to confuse the where to put which datetime, so this is probably not much of an option.
Using the pipe operator would help a bit in this regard, but that I think we can do better. a |> DateTime.before?(b)
I was reading a bit about infix operators but that doesn’t look too promising either for a couple of reasons
The you’d need to import the infix operators before being able to use them.
If the list of free available infix operators is still the same, there are no operators I could recommend with this action.
The third way I thought we could use is a mixture from both previously mentioned approaches: DateTime.compare(a, comparator, b)
As for the comparator, I thought something similar to Enum.sort/2 might be a good idea
# simple
DateTime.compare(a, :<, b)
DateTime.compare(a, :<=, b)
# Natural wording?
DateTime.is?(a, :before, b)
DateTime.is?(a, :before_or_same_as, b)
I tried to searching for discussions to this topic on this forum and a little bit on the GitHub repository, but did not find anything recent, so I thought I’d post my thoughts here and maybe get some feedback about this idea. Do you have other approaches that could be considered?
There has been significant discussion about this in the past on the mailing list.
There were indeed people who liked using :<, := and :> as comparison results, but in the end the core team decided against it.
As for the helper functions you propose: DateTime was included into Elixir’s standard library mainly to have a single datatype that the different date/time-libraries would agree on, rather than each library ending up with its own incompatible types.
This means that only the bare minimum is part of Elixir itself, and all bells and whistles are (only) provided by libraries. Timex is probably the most well-known library that has most of the features you’re talking about, as @al2o3cr already mentioned.
I wasn’t actually looking for an implementation, but rather feedback on what would feel best if it’s put in the standard library But that would pretty much be how I’d implement this function
Do you happen to have any links where I could read this discussion? I would be interested to see their conclusions.
I can understand why they would not like DateTime.compare/2 to return :< and such, but I think it would make sense for the 3rd approach, because there it would be used to indicate how the datetimes shouls be compared and not what the result should be.
I don‘t know the core teams actual reasoning, but plain comparison I feel is only really useful for sorting – and that‘s available in 1.11 using Enum.sort(list, DateTime). My other big use case, where it might be useful is anything related to scheduling, where I found the idea of intervals in combination with Allen‘s Interval Algebra much more useful. Given @wojtekmach wrote calendar_interval this could‘ve been a factor (though unlikely the only one).
Right, Allen’s Interval Algebra seems to be the way to go for comparisons as it’s much more nuanced than :eq, :lt, and :gt. I think it could be added into the stdlib but there’s limited usefulness for Date, DateTime, and Time structs. When calculating Allen’s relation for the structs of the same type, the vast majority of time it’s only possible to get 5 out of 13 available relations (precedes, is preceded by, meets, is met by, and is equal). We could get remaining ones when we compare *Time structs with different microsecond precisions (which doesn’t seem all that useful) or different structs, e.g. DateTime against Date. Allen’s relations would totally make sense for the built-in Date.Range.
Worth mentioning that with the compare/2 functions we can today do:
I don‘t think it‘s actually needed in core. Just stating that there are imo better tools when dealing with comparing datetimes than >/</= comparisons – especially when it comes to scheduling.
But that would pretty much be how I’d implement this function 
