Whilst I don’t have an answer for you on how to embed the timezone in the form, I have an alternative idea (which you might already be aware of!)

In you app.js, you have the following:

let liveSocket = new LiveSocket("/live", Socket, {
  longPollFallbackMs: 2500,
  params: {_csrf_token: csrfToken}
})

You can add to the params the browser timezone, so

let liveSocket = new LiveSocket("/live", Socket, {
  longPollFallbackMs: 2500,
  params: {
    _csrf_token: csrfToken,
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone
  }
})

Then in the LiveView, you can do this

Phoenix.LiveView.get_connect_params(socket)

This would then output

%{
  ...
  "timezone" => "XXX"
}

And then, using that, you could potentially jam it into your changeset…

def changeset(struct, params, timezone) do
  struct
  |> cast(params, [:date_time])
  |> update_change(:date_time, fn date_time -> 
    date_time && DateTime.new!(DateTime.to_date(date_time), DateTime.to_time(date_time), timezone)
  end)
end

The information is not lost so much as it was never gained. The datetime-local inputs explicitly don’t validate the user’s local timezone. It’s literally just a timezone-free datetime input, I have no idea what they were thinking naming it that. Elixir’s NaiveDateTime is a much less confusing name.

Anyway, why not just have a “select timezone” dropdown? That’s the solution recommended in the Mozilla docs. For extra usability you can set the default to the user’s local timezone (a reply above showed how to retrieve it).

Pass the timezone in as a virtual field and then perform the conversion in the changeset.