Need help understanding Timex, date structures, converting timezones, local presentation

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

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

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

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.

Just make sure that if something happens at 1AM on November 2, you pick the right 1AM to convert to UTC

Well, technically it does not matter at all. To my best knowledge, nobody sets up a date in UTC time (pun intended,) maybe some freaks in TAI-land only (pun intended.)

So we are all good picking up any of these two representations, once they both represent an actual Nov 2, 1AM

That’s what I mean, you need to pick one. When storing in UTC, you can’t guarantee that a date can be converted to UTC without resolving ambiguities.

iex(1)> DateTime.new(~D[2025-11-02], ~T[01:00:00], "America/Chicago")
{:ambiguous, #DateTime<2025-11-02 01:00:00-05:00 CDT America/Chicago>,
 #DateTime<2025-11-02 01:00:00-06:00 CST America/Chicago>}

Just pointing out that storing in UTC avoids one can of worms, but there are worms everywhere when it comes to handling time.