Improve DateTime comparisons

Those all seem like one-liners around DateTime — Elixir v1.10.4

def my_compare(a, :<, b), do: DateTime.compare(a, b) == :lt
def my_compare(a, :<=, b), do: DateTime.compare(a, b) != :gt

Let me know if I’m missing some subtlety though.

Your initial idea is decidedly similar to Timex.before?/1 and friends, FWIW

In my opinion this is a much better API then the core implementation, but maybe is only me that doesn’t like :lt, :gt and friends

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

Maybe the standard library should make Compare an official behaviour instead of an unofficial one.

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 am now curious to know why the explicit semantics were not preferred

I have not proposed them, but @gregvaughn was who provided them based on the @Awlexus suggestions

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:

iex(1)> Date.compare(~N[2021-01-01 09:00:00], ~D[2021-01-01])
:eq