All of those types [naive_datetime, naive_datetime_usec, utc_datetime, utc_datetime_usec]
are represented by the same timestamp/datetime in the underlying data storage,
the difference are in their precision and how the data is loaded into Elixir.
I’m guessing the difference in precision is related to the _usec datetime types.
But I’m still wondering - why does Phoenix use :naive_datetime by default for timestamps? From all these discussions I either get the impression that it does not matter or that it’s slightly better to use :utc_datetime. However, in this topic I’m not trying to start a conversation comparing the two like as much as understand the default choice for Phoenix.
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.
Thank you for the reply! I did read the comment you quoted at least a few times but it seems I did not pay enough attention to this sentence.
In light of this I would then ask - what is different with :utc_datetime for backwards compatibility if both naive and utc datetime are ultimately the same in the database? Is it that it was always :naive_datetime and if it’s changed to :utc_datetime people would have to change the module they use in every place they load datetimes? If that’s the case, what was the reason to use :naive_datetime in the first place? If I’m not mistaken, both DateTime, which is used for :utc_datetime, and NaiveDateTime were added to Elixir in version 1.3.
Keep in mind that tools for timezone manipulation only landed in core at version 1.8. Before that third party tools were needed to do any timezone calculations. In a library you don’t want to use defaults, which more or less require users into needing to use other libraries. Even in 1.8 the actual tz database is still required to be supplied by the developer or a third party library.
Also while those structs were introduced in 1.3 ecto came with its own set of datetime structs before that, which ecto probably tried to be as backwards compatible to as possible.