mgwidmann
`DateTime.from_naive!/3` error for EST->EDT time switch
My production (hobby) system started encountering errors tonight which look to be related to the time change. Heres the error:
** (ArgumentError) cannot convert ~N[2023-03-12 02:17:24] to datetime because such instant does not exist in time zone America/New_York as there is a gap between #DateTime<2023-03-12 01:59:59.999999-05:00 EST America/New_York> and #DateTime<2023-03-12 03:00:00-04:00 EDT America/New_York>
[info] (elixir 1.14.1) lib/calendar/datetime.ex:629: DateTime.from_naive!/3
[info] (flames 0.7.0) lib/flames_web/dashboard/helpers.ex:52: Flames.Dashboard.Helpers.display_timestamp/1
[info] (flames 0.7.0) lib/flames_web/dashboard/errors_live.ex:82: anonymous fn/4 in Flames.Dashboard.ErrorsLive.render/1
[info] (elixir 1.14.1) lib/enum.ex:2468: Enum."-reduce/3-lists^foldl/2-0-"/3
[info] (flames 0.7.0) lib/flames_web/dashboard/errors_live.ex:56: anonymous fn/2 in Flames.Dashboard.ErrorsLive.render/1
[info] (phoenix_live_view 0.18.16) lib/phoenix_live_view/diff.ex:398: Phoenix.LiveView.Diff.traverse/7
[info] (phoenix_live_view 0.18.16) lib/phoenix_live_view/diff.ex:139: Phoenix.LiveView.Diff.render/3
[info] (phoenix_live_view 0.18.16) lib/phoenix_live_view/static.ex:252: Phoenix.LiveView.Static.to_rendered_content_tag/4
The code which does this is located here:
In this case, it appears that the timezone cannot be converted because it lands in between the shift. Wouldn’t the appropriate action here, rather than a failure which occurs for an hour once a year (which is incredibly difficult to predict), be to just add 1 hour since it seems to already know that 2am goes to 3am and anything between 2am and 3am is actually just 3am+.
Why does the standard library put an exception that can happen so rarely like this? My system is down for the next 35 minutes I suspect until UTC time is past 3am.
Most Liked
benwilson512
First, sorry for the production issues, that’s always unpleasant.
The thing is though, the standard library does not know that adding an hour is a valid interpretation of the data in the general case. It might be in your case, but you could just as easily be here on the forum reading a post by someone else about how the standard library silently advances inputs an hour during DST which leads to invalid duration logic (for example). Standard libraries should, in my opinion, err on the side of correctness, particularly in cases like date and time logic where there’s a lot of essential complexity.
As for how you would handle this, I would question where the datetime applied to display_timestamp comes from in the first place. Where are you getting the data for this instant in time given that, as Elixir notes, it does not exist?
dfalling
I’ve gone through four iterations of storing dates, times, and timezones in my DB and finally learned about “wall time” from this great discussion. Strongly recommend reading through that and seeing if like me it would make more sense for you to store your dates as naive with a separate timezone field.
trisolaran
Wall time is kind of a special case though. If you’re only interested in storing a specific point in time (such as the timestamp from a past event) as opposed to “4pm in New York on a certain future date”, then you don’t need to store the time zone.
Taking a look at the OP example, it seems to me that his application is storing timestamps.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
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.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"