In my view the difference is semantics.

• :utc_datetime is very clear that UTC is it’s frame of reference
• :naive_datetime retains ambiguity as to what the frame of reference is. It’s up to the application context to imply and/or supply the frame of reference.
  • In the absence of any other evidence UTC is the only sensible choice.
  • In the application context of being used as a Phoenix timestamp it is known to be UTC.

So just because it’s :naive_datetime doesn’t automatically imply it’s not UTC.

• Jun 21, 2016 Elixir 1.3
• Aug 28, 2015 Phoenix 1.0
• Aug 25, 2015 Ecto 1.0

Thank you both for the replies once more, and, I must say, for your contributions to other topics too.

I noticed this comment by Michał Muskała, which also seems helpful for my question - Deprecation warning says to use :naive_datetime but I'd like to use :utc_datetime - #5 by michalmuskala

Just to clarify. The warning says to use :naive_datetime since that’s the type 
with exactly the same behaviour as the old Ecto.DateTime. 
The :utc_datetime has slightly different semantics.

You already linked to this

The reason why Ecto’s timestamps() are naive by default is backwards compatibility.

In what way doesn’t that address your question?

It is my impression that the core team by convention treats time data without a timezone as UTC.

Confusion typically arises with people coming from other backgrounds who may have been working with a different convention - assuming that timezone free data is recorded with reference to local server time or local client time - which may be immediately convenient in the local context but creates problems in a long term historical or global context.