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.

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).

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.

I’ll gladly leave my brainfart here in case someone else runs into this, and they don’t know why. Thanks!

I appreciate you pointing this out. Timex is another tool I had in the dependencies from decisions made years ago. If you give a kid a hammer, the world becomes a nail, I suppose.

You’re also correct in the schema assertion. Setting @timestamps_optstimestamps_opts [type: :utc_datetime] in the schema or in the timestamps macro: timestamps(type: :utc_datetime) solves this problem as well.