wallyfoo
Need help understanding Timex, date structures, converting timezones, local presentation
This has been vexing me for a couple of days now, and I finally had a breakthrough. When I’m done with the explanation, please tell me: is this just obvious on the face of it? Or does this really not make sense with what Timex should be doing for me?
I am making a tool that I know is going to be used in the “America/Chicago” timezone. This is a very old database that has had a number of improvements and iterations over the years, and for reasons long forgotten, the inserted_at and updated_at are being stored as “timestamp(0) without time zone”. So, timestamps are being returned from the database as naive:
~N[2025-08-22 16:35:54]
I was taking this sigil and passing it directly to Timex to represent it in CST/CDT and format accordingly. Everyone using this app is going to be sitting in the same room in Texas for one week of the year.
~N[2025-08-22 16:35:54]
|> Timex.to_datetime("America/Chicago")
|> Timex.format!("{M}/{D}/{YYYY} {h12}:{m} {AM}")
“8/22/2025 4:35 PM”
Wait a second. That’s just the naive date time formatted. I absolutely expected Timex to cope with this. When I inspect the Timex.to_datetime(“America/Chicago”) line in this one, I get what looks correct: #DateTime<2025-08-22 16:35:54-05:00 CDT America/Chicago>
~N[2025-08-22 16:35:54]
|> DateTime.from_naive!("Etc/UTC")
|> Timex.to_datetime("America/Chicago")
|> Timex.format!("{M}/{D}/{YYYY} {h12}:{m} {AM}")
“8/22/2025 11:35 AM” ← this is the correct time in Texas from the starting point.
Explicitly casting to UTC first gets the correct result from Timex. In fact, if I swap the Datetime.from_naive/2 to Timex.to_datetime/1, the final result is the local central time (correct). Or when I do Timex.to_datetime(“Etc/UTC”) first. When I go straight from naive to the America/Chicago timezone, the formatting in the final step is for the NaiveDateTime.
This doesn’t feel correct. So, please tell me why I’m dumb.
Marked As Solved
benwilson512
So I think the part you’re missing is that you’re expecting it to treat a naive date time as if it’s in UTC by default. The whole point of NaiveDateTime is that it has zero timezone information at all. So the first thing you need to do is say “I’m telling you that these digits are a utc timezone date time” then you can go “now convert this to the equivalent time in Chicago”.
Your first attempt was saying “I’m telling you that these digits are Chicago time”.
Also Liked
adamu
Worth mentioning that you don’t need Timex for this:
~N[2025-08-22 16:35:54]
|> DateTime.from_naive!("Etc/UTC")
|> DateTime.shift_zone!("America/Chicago")
|> Calendar.strftime("%-m/%-d/%Y %I:%M %p")
"8/22/2025 11:35 AM"
Additionally, if you are using Ecto, you can probably set the schema to utc_datetime to get a DateTime in UTC, allowing you to skip the naive datetime.
annad
I highly recommend that you check out TzDatetime. It made my life so much easier when it comes to date/times. It can be a serious rabbit hole when have to start dealing with daylight savings. This library handles it for you. I end up storing both the naive datetime, utc datetime and offset. The user always sees the time in their naive datetime and the UTC is used for translating the datetime to other people’s timezones (I’m dealing with international events so this was critical).
garrison
Keep in mind that, as the examples in the docs show, it is possible for the conversion from NaiveDateTime to DateTime to actually fail if the date/time do not actually exist in that timezone (e.g. due to daylight savings). You are avoiding that can of worms by storing UTC.
I recommend going for utc_datetime_usec instead (see primitive types), which should really be the default (but can’t be changed now).
The first thing I do in any new Ecto project is set the default timestamps to utc_datetime_usec for schemas and migrations. It’s just easier to store them all with microsecond precision rather than worry about it.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Move fast and fix things! Error tracking with less noise for Elixir devs who love to ship. Start your free dev account.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"