Elixir: NaiveDateTime with "0" microseconds and nil microseconds comparison bug

[mfclarke]

Environment

• Elixir & Erlang versions (elixir --version): 1.5.1
• Operating system: macOS 10.12.5

Current Behaviour

iex> date1 = ~N[2016-07-29 11:00:00]
~N[2016-07-29 11:00:00]
iex> date2 = ~N[2016-07-29 11:00:00.000000]
~N[2016-07-29 11:00:00.000000]
iex> NaiveDateTime.diff(date1, date2)
0
iex> NaiveDateTime.compare(date1, date2)
:eq

Makes sense. But:

iex> date1 < date2
true

Expected Behaviour

I would expect date1 < date2 to be false

[ivanovaleksey]

@mfclarke I am very new to Elixir, but I read something about that in the "Programming Elixir" book.
It is written there

The Time type contains an hour, minute, second, and fractions of a second.The fraction is stored as a tuple containing microseconds and the number of significant digits.
The fact that time values track the number of significant digits in the seconds field means that ~T[12:34:56.0] is not equal to ~T[12:34:56.00]

Seems like it is expected behaviour.

[mfclarke]

@ivanovaleksey yes you're right, that makes sense from a struct value equality perspective because they contain different information (one has 000000 microseconds, the other nil microseconds).

But for the sake of greater than / less than comparisons, it makes sense to me that it should be comparing on overall value. Especially given the compare/2 func returns :eq.

Here's another example that demonstrates the (IMHO) expected behaviour, but with a different type:

iex(1)> 2.0000 > 2
false
iex(2)> 2.0000 < 2
false

[josevalim]

You cannot use structural comparison (which is <, >, and friends) with
Calendar types. Things like precision will not allow them to be

structurally equal even if they are semantically equal.

José Valim
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

[mfclarke]

Ah, so <, > etc are structural comparisons. My mistake! Closing the issue. Many thanks @josevalim and @ivanovaleksey