Exadra37
In my understanding when we use NaiveDatetime for timestamps in ecto we loose the timezone information, thus I am having an hard time understanding how they can be useful when I don’t know their timezone.
So let’s consider the case where your server is wrongly configured for the timezone, lets say UTC+5, and then you fix it to be UTC+0, then all your records in the database will overlap for that period, but if the timestamps were in UTC+0, then this wouldn’t be a problem.
The main point I want to understand is if I am using a NaiveDatetime that I don’t know from what timezone it was created, then how can I really used it in a useful way from the inserted_at and updated_at, because when reading that values they can represent any timezone, and even if I inspect the timezone currently used on the server, I don’t have any guarantee they where generated from that timezone.
Maybe I am really missing the point of not using UTC timestamps for the inserted_at and updated_at, and if so can someone point me to a good resource explaining why UTC is not being used.
Or Am I misunderstanding NaiveDatetime?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Marked As Solved- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
That’s the case. The api is named
NaiveDateTime.utc_nowfor a reason. Without an external timezone db elixir doesn’t even know of timezones outside ofEtc/UTC. You can still mess this up though if your machines clock is not correct though, but that’s nothing elixir can cater for.Also Liked
LostKobrakai
I generally create a custom schema macro + migration config, which sets timestamps to
:utc_datetime_usecwhen starting a project.But I feel there are a few misconceptions to clear up as well:
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_datetimedoes enforce that the datetime was supplied withEtc/UTCtimezone, while the naive counterpart has no timezone to enforce. When loading data from the db:utc_datetimeexpects the timestamp to be in UTC.Postgres has a
timestamptz, but contrary to it’s name it doesn’t store a timezone just liketimestamp. The difference is that fortimestamptzpostgres 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 withtimestampcolumns.timestamptzcan 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_datetimeor:utc_datetime. As for why ecto defaults to:naive_datetimeI’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.dimitarvp
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.
Last Post!
Exadra37
Thanks for pointing it out. It was not clear from reading the Ecto docs that the timestamps are being created with it.
And when I looked into NaiveDateTime docs It was not clear to me either, maybe because
utc_nowis the last one in that docs, and everything from the start in that page doesn’t lead you into UTC being used