Awlexus
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?
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #elixirconf-us
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
gregvaughn
Those all seem like one-liners around DateTime — Elixir v1.10.4
Let me know if I’m missing some subtlety though.
al2o3cr
Your initial idea is decidedly similar to
Timex.before?/1and friends, FWIWExadra37
In my opinion this is a much better API then the core implementation, but maybe is only me that doesn’t like
:lt,:gtand friendsQqwy
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.
Awlexus
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 
ityonemo
Maybe the standard library should make Compare an official behaviour instead of an unofficial one.
Awlexus
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/2to 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.Exadra37
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
LostKobrakai
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).wojtekmach
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 forDate,DateTime, andTimestructs. 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-inDate.Range.Worth mentioning that with the
compare/2functions we can today do: