Naive Datetime values comparison using < and > operators

</2 and >/2 work as expected and documented here.

They do a structural comparison. If you want to do a value comparison of those, please use NaiveDateTime.compare/2

Can you please tell me how does NaiveDateTime.compare/2 and structural comparison work?

From the erlang documentation:

Maps are ordered by size, two maps with the same size are compared by keys in ascending term order and then by values in key order. In maps key order integers types are considered less than floats types.

This means in structural comparison the :day key has precedence over the :month key. So for any value in :month the higher :day value will sort last.

ok, that helps

So, is the Naive DateTime basically a map?

Yes, as any other struct.

You can take a peek at the internal structure by using IO.inspect/2 and it’s option structs:

iex(7)> NaiveDateTime.utc_now() |> IO.inspect(structs: false)
%{
  __struct__: NaiveDateTime,
  calendar: Calendar.ISO,
  day: 17,
  hour: 12,
  microsecond: {614456, 6},
  minute: 37,
  month: 9,
  second: 47,
  year: 2019
}

That’s how all structs work in Elixir.

Thank you

I know this is an old topic and I understand that using < does structural comparison.

But I just discovered a bad bug in my application that was super nasty to track down.
I had first_entry = entries |> Enum.min_by(& &1.inserted_at) somewhere in critical business logic.
Obviously, this code is wrong, it should be:

first_entry = entries |> Enum.min_by(& &1.inserted_at, NaiveDateTime)

Having found this bug, I’m now paranoid that this incorrect use of < is hiding in potentially many other places.

My tests didn’t catch this, since they used accidentally correctly sorting dates.

Is there a way to find these sort of issues?
Would the new type system be able to catch this?
Could credo catch this?

Structural comparison of dates was actually used as an example of the new type system when it was introduced! At the moment I don’t believe it can catch this within a function like Enum.min_by() (obviously since it didn’t for you), but there are more type system changes coming in 1.19 and 1.20 which have to do with functions, so perhaps it will eventually?