Difference between 2 DateTime in hours in Elixir - datetime

Question

My goal is to find a difference in hours between now and some provided date_time. I'm trying to do this this way:
pry(1)> dt1
#DateTime<2017-10-24 05:12:46.000000Z>
pry(2)> Ecto.DateTime.to_erl(dt1)
** (FunctionClauseError) no function clause matching in Ecto.DateTime.to_erl/1
The following arguments were given to Ecto.DateTime.to_erl/1:
# 1
#DateTime<2017-10-24 05:12:46.000000Z>
Attempted function clauses (showing 1 out of 1):
def to_erl(%Ecto.DateTime{year: year, month: month, day: day, hour: hour, min: min, sec: sec})
(ecto) lib/ecto/date_time.ex:608: Ecto.DateTime.to_erl/1
# ............
How to fix that? Or is there a better way to achieve my goal?
Note that I don't use timex and won't use it, neither any third-party library. Only ones built-in in Elixir/Erlang/Phoenix.

Answer 1

You can use DateTime.diff/3:
iex> dt1 = %DateTime{year: 2000, month: 2, day: 29, zone_abbr: "AMT",
...> hour: 23, minute: 0, second: 7, microsecond: {0, 0},
...> utc_offset: -14400, std_offset: 0, time_zone: "America/Manaus"}
iex> dt2 = %DateTime{year: 2000, month: 2, day: 29, zone_abbr: "CET",
...> hour: 23, minute: 0, second: 7, microsecond: {0, 0},
...> utc_offset: 3600, std_offset: 0, time_zone: "Europe/Warsaw"}
iex> DateTime.diff(dt1, dt2)
18000
iex> DateTime.diff(dt2, dt1)
-18000
Since DateTime.diff/3 returns seconds you have to calculate the hours out of the result like this:
result_in_hours = result_in_seconds/(60*60)

Answer 2

This answer has been added before topic author edited his question and excluded external libs from the scope. However, I'm not deleting it as I find Timex extremely useful and maybe someone will be interested in using it as well (I have nothing to do with Timex creators)
I strongly recommend using Timex library. It's perfect for date/time calculations with different formats and time zones.
So in your case to easily calculate hour difference you just need to:
Timex.diff(dt1, DateTime.utc_now, :hours)
You can find diff/3 docs here.

Answer 3

Ignoring timezones entirely here (to do that it is easiest to convert everything to UTC, then cast to whatever is local), the pure Erlang way is to do something along these lines.
1> Event = {{2017,05,23},{13,11,23}}.
{{2017,5,23},{13,11,23}}
2> Now = calendar:local_time().
{{2017,10,24},{14,44,1}}
3> EventGSec = calendar:datetime_to_gregorian_seconds(Event).
63662764283
4> NowGSec = calendar:datetime_to_gregorian_seconds(Now).
63676075441
5> Elapsed = NowGSec - EventGSec.
13311158
6> calendar:seconds_to_daystime(Elapsed).
{154,{1,32,38}}
The exact solution would depend, of course, on the resolution that you require. Extracting that into a function that returns a tuple of the form {Days, {Hours, Minutes, Seconds}} gives us:
-spec elapsed_time(calendar:datetime()) -> {Days, Time}
when Days :: non_neg_integer(),
Time :: calendar:time().
elapsed_time(Event) ->
Now = calendar:local_time(),
EventGSec = calendar:datetime_to_gregorian_seconds(Event),
NowGSec = calendar:datetime_to_gregorian_seconds(Now),
Elapsed = NowGSec - EventGSec,
calendar:seconds_to_daystime(Elapsed).
(Of course, the above could be composed on a single line -- but why would you ever do that?)
I'm sure there are some wazoo Elixir libraries that do things in a totally different way. Have fun with those. This answer only addresses the underlying native libraries. Most of the time functions in the Erlang standard library are now based on integer-based time units (seconds, milliseconds, or nanoseconds) instead of the older erlang:now() timestamp form (which is now deprecated). The exact way you should write your version of the function above depends on what kind of resolution you require and formatting of the original input (Unix-era nanoseconds are quite common for the type of timestamps I deal with myself, for example -- but are inapplicable to a datetime data type).
Remember: time calculations are tricky, subtle and hard to get right in edge cases. The standard libraries for most languages actually get quite a lot of TZ and time diff issues wrong -- and if that's OK for your case then just don't worry about it. In any case, I suggest at least skimming the Time and Time Correction in Erlang page of the standard docs -- even if it does not apply to your current situation, eventually you'll probably be in a situation where subtle timing issues will matter.