I generally create a custom schema macro + migration config, which sets timestamps to :utc_datetime_usec when starting a project.

But I feel there are a few misconceptions to clear up as well:

1. A the database level there’s no difference between :naive_datetime and :utc_datetime. Both are stored as timestamps. The difference is only at runtime, where on storage :utc_datetime does enforce that the datetime was supplied with Etc/UTC timezone, while the naive counterpart has no timezone to enforce. When loading data from the db :utc_datetime expects the timestamp to be in UTC.

2. Postgres has a timestamptz, but contrary to it’s name it doesn’t store a timezone just like timestamp. The difference is that for timestamptz postgres will try to convert datetimes to (and from) utc on its own. So with ecto you’re better of not having that, as ecto handles that part at runtime and you’ve one thing less to worry about with timestamp columns. timestamptz can make sense if you’re using the db not just with ecto.

So to conclude. Your db never actually stores a timezone, so from that standpoint it’s completely irrelevant if you’re using :naive_datetime or :utc_datetime. As for why ecto defaults to :naive_datetime I’d guess it’s because of backwards compatibility (but that could’ve been changed with ecto 3) and maybe the fact that elixir core does not ship with a timezone database, so it can only handle UTC as a timezone.

Seeing as [in my experience] most people want a quick advice to get started and not have to write DB timestamp fixing scripts later, that advice is good enough IMO. Nuances of course always exist.