The date-time format allows both local and 'timezoned' values (both are allowed by ISO_8601).

Although there can be use cases where local time is desired (say, flight arrival time at destination, without having to know the timezone offset at that date), in a great number of cases allowing the lack of timezone information is undesired, because it is unclear what the local time is supposed to be (browser clients can be in any timezone).

In fact, from my experience, sending a 'timezoneless' value will most often be a sign of a bug in the client (someone forgetting to use a proper UTC backed value or forgot to apply correct formatting), while the server accepting such a value will be a bug on the server - insufficient validation. Both of them combined will inevitably lead to a hard-to-spot data corruption.

1. The proposal is to create a separate format that forbids passing values without timezone indicator.
   • Name could be: date-time-localizable, date-time-convertible, date-time-tz, but feel free to suggest better ones.
2. Also, one could argue that, even though a use case for local time does exist (as the flight arrival example shows), a developer of such service would find it useful to bounce back any requests that contain the timezone designator, because it too might be a sign of user performing an inadvertent conversion (e.g. using JavaScript Date() on the local client and not preventing the conversion that some libraries can choose to perform 'by default').
   • A name for this could date-time-local or date-time-no-tz, date-time-without-tz, date-time-tz-free.

(I'm especially interested in number 1. Number 2 is mostly as a side-suggestion to get feedback for.)