Ecto is doing it because over binary protocol that postgrex uses, timestamp and timestamptz is precisely the same thing.

Most postgresql connectors use text based protocol, in other languages. Postgrex uses binary protocol. It doesn’t understand client’s time zone.

I do think that, however, timestamptz is a safer choice, especially when other clients can connect to database. For example, if you ever connect using psql, you could see dates & times in different time zone because of your client configuration and then this can even lead to mistakes. I guess it’s OK if you are aware of the issue. But for the consistency and possible error avoidance, I like to uze timestamptz everywhere which forces the dates to be displayed in UTC no matter what your client is.

I have written about it more in details here: Time zones in PostgreSQL, Elixir and Phoenix | AmberBit Sp. z o. o.

At least 4.1, but there are valid reasons to not follow the advice.

NaiveDateTime already doesn’t involve timezones and DateTime is enforced to have UTC set as timezone at the time of insertion (runtime). So timestamp is the better default over timestamptz because you can be sure the database won’t ever try to convert the timestamp. Basically ecto is already doing what timestamptz is supposed to do over timestamp but it does so in it’s own control.

Also I’d imagine the ecto team is well aware of what they’re doing.
See this for a response on the above: utc_datetime having no affect on PostgreSQL DDL · Issue #1868 · elixir-ecto/ecto · GitHub

That is why I use :text almost always when want to store string in the DB.