Why use `utc_datetime` over `naive_datetime` for Ecto?

[LostKobrakai]

@itssasanka

And I also think storing timestamptz values in the database may not be really required, since I can just store utc timestamps everywhere and user timezone preferences in another table and use these two pieces of info to convert accordingly before presenting to the users.

You’re correct. timestamp columns are actually better for ecto (alone) as with timestamptz postgres will try to convert the timestamp to the clients timezone on its own. While for timestamp you can be sure postgres just leaves timestamps as is, with ecto handling all the timezone stuff at runtime using the settings/timezone db of elixir.

@itssasanka

I read that using utc_datetime “ensures” that dates are always converted to utc before getting stored/retrieved from and to the database, however I am not sure what the significance of the “ensures” aspect here is, since naive_datetime seems to do it anyway.

naive_datetime does store timestamps as UTC datetimes – that’s true. But that’s only “accidental” because it’s using NaiveDateTime.utc_now() to generate timestamps. If you manually set such fields to a different naive datetime you build from another timezone there’s no way for ecto to detect that. NaiveDateTime structs just don’t have a timezone component, which is the reason why they’re called naive.

For utc_datetime ecto will enforce that any saved datetime uses the Etc/UTC timezone. It’ll error otherwise. If you query the record you’ll also get back only datetimes with tthe timezone set to UTC. So the fact that datetimes use UTC changed from being implicit and prone to error with naive_datetime to explicit and enforced at runtime with utc_datetime.