Datetime input and time zone

Phoenix Forum Questions / Help
, , ,
1

I have been searching for a way to deal with datetime values coming from forms. The datetime-local input does not care about time zones, so the information is lost and casting to Ecto’s :utc_datetime assumes the value already is in UTC.

I think the front end should add the time zone instead of this being handled anywhere else (like a custom Ecto.Type), since it is the only place that knows the actual time zone of the user, but I have not been able to find a solution.

Is there a way to map the value of an input before the params get sent to the server? Should I just give up on datetime-local and use some kind of a custom input component? Is there an existing component for this? Or is there a completely different approach to this that I have not considered?

It has been driving me crazy for the last two days that I cannot get a basic form to work properly because of this, so any ideas will be very much welcome.

2

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
1 Like
3

Can you embed the timezone or offset as a hidden field in your form?

4

I have been thinking about doing something like this, but I seriously dislike that the time zones need to be handled explicitly in the changeset functions. That is guaranteed to introduce a bug pretty much every time.

I agree that a hidden field is probably the way to solve this. In order to have a regular :utc_datetime work, the hidden field would need to contain the datetime with the time zone together, rather than be a separate field with just the timezone. I should probably give this a try when I have recharged my mental capacity :sweat_smile:

I’m mostly just surprised that nobody seems to have solved this properly before.

5

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.

1 Like