While the FormData formats of DateField (2024-02-24) and TimeField (19:55) suffice and are close enough to ISO 8601, the format of DateTimeField is not (2024-02-24T19:55 without seconds or time zone). In form_data it should be what the user's browser sent us, but in values it should be converted first to the full ISO 8601 UTC format of 2024-02-24T17:55:00Z and finally, as of #436, to the scope time zone such as 2024-02-24T19:55:00+02:00.
The <input type="datetime-local"> does not convey the time zone but implies it is the user's time zone. In places where we send formData: Object.entries(formData), we should probably include our best guess of the user time zone either added into the formData or next to it. (OR: Should we understand this to be always in the scope time zone? Case US organizer of a FI event setting the program schedule publishing time)
There are occasions of TODO(#436) in the frontend source code signalling places where we could be using DateTimeField if this was taken into account, but currently are not.
While the
FormDataformats ofDateField(2024-02-24) andTimeField(19:55) suffice and are close enough to ISO 8601, the format ofDateTimeFieldis not (2024-02-24T19:55without seconds or time zone). Inform_datait should be what the user's browser sent us, but invaluesit should be converted first to the full ISO 8601 UTC format of2024-02-24T17:55:00Zand finally, as of #436, to the scope time zone such as2024-02-24T19:55:00+02:00.The
<input type="datetime-local">does not convey the time zone but implies it is the user's time zone. In places where we sendformData: Object.entries(formData), we should probably include our best guess of the user time zone either added into theformDataor next to it. (OR: Should we understand this to be always in the scope time zone? Case US organizer of a FI event setting the program schedule publishing time)There are occasions of
TODO(#436)in the frontend source code signalling places where we could be usingDateTimeFieldif this was taken into account, but currently are not.