1846571 - Surprising interpretation of constraints by <input type=datetime-local> when time format includes seconds

Status: RESOLVED INVALID

(Core :: DOM: Forms, defect, P3)

Description

[Quentin Santos]

Attachment: Entering a value after the specified min is considered invalid

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Provide a min constraint to a <input type=datetime-local> but include seconds:

<style>
:invalid { border:2px solid red; }
</style>
<p>
    <input min="2023-08-01T19:14" type="datetime-local">
    min="2023-08-01T19:14"
</p>
<p>
    <input min="2023-08-01T19:14:58" type="datetime-local">
    min="2023-08-01T19:14:58"
</p>
<p>
    <input min="2023-08-01T19:14:58.406" type="datetime-local">
    min="2023-08-01T19:14:58.406"
</p>

Actual results:

When typing a full value, the field is considered invalid. This only happens for the versions that do include seconds in the min constraint.

The field is actually considered value when the seconds in the field match the seconds in the min constraint. So 01/08/2023 19:15:58.406 is considered valid, since it is both in the feature and a matching second part.

Also, note that the format of the field changes to allow inputting seconds and milliseconds depending on the format of the min constraint. Setting the step attribute does not change anything.

Expected results:

The documentation on <input type=datetime-local> says:

The earliest date and time to accept; timestamps earlier than this will cause the element to fail constraint validation. If the value of the min attribute isn't a valid string that follows the format YYYY-MM-DDThh:mm, then the element has no minimum value.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local#additional_attributes

When including seconds, the value does not follow the prescribed format. So we would expect there to be no minimum value and the field to always be valid.

Another reasonable expected behavior would be for the second part to be entirely ignored. Or to be interpreted as part of the cutoff date (not as an independent constraint on the seconds).

As an addition, the documentation also says:

Note: With a datetime-local input, the date value is always normalized to the format YYYY-MM-DDThh:mm.

However, the format of the value of the field actually follows that of the min constraint in the example above.

Comment 1

[Adam Vandolder [:avandolder]]

The MDN description of the valid min/max datetime values should include seconds according to the spec, that seems to be an oversight of the documentation. The seconds value should definitely be interpreted as part of the cutoff date, and seems to work that way in my tests. Is it possible your datetime values are being considered invalid because of a step mismatch? The default step value for datetime-local inputs is 60 seconds, and your provided example has values that are less than 60 seconds after the min value. Try adding a step="any" attribute to your inputs and see if that fixes your problem.

This jsfiddle demonstrates what I think the issue is you're having: https://jsfiddle.net/x4pjv7u1/

Comment 2

[Quentin Santos]

Attachment: With `step="any"`

Good catch with the step attribute! Setting step="any" indeed fixes the weird behavior. Seconds seem like they are being taken into account for the cutoff, when step is changed this way. Thanks!

<style>
:invalid { border:2px solid red; }
</style>
<p>
    <input min="2023-08-01T19:14" type="datetime-local" step="any">
    min="2023-08-01T19:14"
</p>
<p>
    <input min="2023-08-01T19:14:58" type="datetime-local" step="any">
    min="2023-08-01T19:14:58"
</p>
<p>
    <input min="2023-08-01T19:14:58.406" type="datetime-local" step="any">
    min="2023-08-01T19:14:58.406"
</p>