josevalim
commented
1 year ago This is very complicated and outside of the scope of this library. This is because, if the datetime happens in the future, then you should not have a utc_datetime, but a naive datetime with the timezone stored in a separate field, since timezone definitions change. So at best, we could have past_datetime_input. Also, the fact this feature would require either multiple inputs (which may require custom styling) or custom JS, pretty much leaves it out of scope for this library.
At the moment, the only input element for DateTime fields is
datetime_local_input(form, field, opts \\ []), which does not take time zones into account when writing to nor when reading from Ecto. Effectively, the existing input only fully works for NaiveDateTimes, while ditching time zone offset data for any DateTimes it's handed (as its initial value) or handed to (on submit).This leads to a lot of headaches for projects facing users in different time zones. Ecto recommends using :utc_datetime to store datetimes. As a result, binding a Phoenix form to an Ecto object will lead to the form input both displaying and expecting a UTC datetime in all cases, whereas users of the form would expect to be working within their own local time zone.
Ideally, all times would be stored in :utc_datetime (as per the Ecto recommendation), and then convert to/from the user's time zone in the form. To facilitate this, a DateTime input could either: a) accept an optional time zone parameter, or b) detect the user's time zone settings through the browser (through Intl.DateTimeFormat().resolvedOptions().timeZone, for instance)