Space as date/time separator

[tkent-google]

Specification:
https://html.spec.whatwg.org/multipage/forms.html#local-date-and-time-state-(type=datetime-local)
https://html.spec.whatwg.org/multipage/infrastructure.html#valid-local-date-and-time-string

WPT tests:
http://w3c-test.org/html/semantics/forms/the-input-element/datetime-local.html
http://w3c-test.org/html/semantics/forms/constraints/form-validation-validity-valueMissing.html

2. A U+0054 LATIN CAPITAL LETTER T character (T) or a U+0020 SPACE character

So, <input type=datetime-local value="2017-01-20 18:09"> has a valid value. However, existing type=datetime-local implementations (Mobile Safari, Google Chrome, and Edge) supports only T separator.

This micro syntax is used in <time datetime=...> too though UAs do nothing for it.

Proposal: <input type=datetime-local> accepts only valid normalized local date and time string instead of local date and time string.

[zcorpan]

The proposed change would also disallow :00 seconds:

A valid time string representing the time, expressed as the shortest possible string for the given time (e.g. omitting the seconds component entirely if the given time is zero seconds past the minute)

I think the space is allowed to make it a bit more human-readable when using time text content:

<time>2011-11-18 14:54:39</time>

but maybe it could be required to use T there as well, and use datetime attribute if one wants the text content to use a different format...

[tkent-google]

The proposed change would also disallow :00 seconds:

Oh, you're right. My intention was just disallowing space separator, and :00 should be accepted.

[zcorpan]

In httparchive (~500,000 pages) I see 6126 pages using time without datetime attribute. 163 pages with time text content has valid date and time with the space. 0 with valid date and time using a T.

[Marat-Tanalin]

@tkent-google

Proposal: <input type=datetime-local> accepts only valid normalized local date and time string instead of local date and time string.

AFAICT based on Chrome and Edge, <input type=datetime-local> provides a masked input where the user does not deal with direct input of date as text, so it’s somewhat fine for its internal date format to be machine-readable and not human-readable, though I’m not sure this really makes much sense given that the resulting datetime is then anyway sent to server as text that then could be output as is on a webpage, while the proposed limitation would require further server-side reformatting that could probably be avoided.

Given that <input type=datetime-local> is not widely supported yet, it may make sense to change its datetime representation to use space instead of T, and change the format solely for <input type=datetime-local> without affecting the global datetime format in any way.

@zcorpan

the space is allowed to make it a bit more human-readable when using time text content

Exactly. The point of allowing space inside the TIME element was to allow the date to be human- and machine-readable at the same time and therefore to prevent unreasonable duplication of the entire date, just with different date/time separators like this:

<time datetime="2017-01-20T18:09">2017-01-20 18:09</time>

but maybe it could be required to use T there as well, and use datetime attribute if one wants the text content to use a different format...

I believe this is a bad idea. Changing the global datetime format now for the purpose of some theoretical consistency between the TIME element and internal <input type=datetime-local> representation at the cost of human convenience and web compatibility would be an unreasonable and harmful mistake.

Fwiw, I’m who has originally proposed space as allowed date/time separator in the TIME element and one of those who actively use the TIME element with no attributes for years.

[zcorpan]

@Marat-Tanalin this is not about internal representation (which would probably be a Date object or some such, not a string), but about what authors write in <input type=datetime-local value="...">

[Marat-Tanalin]

@zcorpan That’s clear. Given that, indeed, value of <input type=datetime-local> may be written by a human, nothing should probably be changed in the spec, and implementations should support space as date/time separator.

[zcorpan]

A "T" is as human-writable as a space. The input case is not shown to end-users, except in legacy browsers that don't support datetime-local.

Since we have interop on only-T for the input case, and an implementor suggests changing the spec rather than changing the implementations, it is not so much up for discussion about whether we should change the spec IMO.

What is up for discussion is what to do about the time element. Given the httparchive data above I suppose we should continue to allow space there, and live with it being inconsistent with input.

[Marat-Tanalin]

A "T" is as human-writable as a space.

What has once been written by a human is then almost inevitably read by a human during maintenance.

what to do about the time element. Given the httparchive data above I suppose we should continue to allow space there, and live with it being inconsistent with input.

Indeed.

[annevk]

I think the space is what makes us inconsistent with the ISO standard for dates and also JavaScript. See also https://mail.mozilla.org/pipermail/es-discuss/2013-April/030207.html.

[zcorpan]

Thanks @annevk. So TC39 did not adopt the space it seems.

Having inconsistent rules between JS and HTML sucks. Having inconsistent rules between different features in HTML would still suck. I would prefer one of the following:

• JS adopts the space, and browsers change to accept the space in JS and HTML input.
• or: we change HTML to allow only T for all dates (including for time element).

I understand some people (including @Marat-Tanalin) would be unhappy if we make them start using datetime attribute, but in httparchive this is only 163 pages, which is ~2.7% of pages using time element without datetime, and ~0.03% of all pages in httparchive. Since browsers don't process time elements, the effect is just new errors in conformance checkers, I believe.

cc @sideshowbarker

[Marat-Tanalin]

I don’t actually see what the real issue is. Supporting both T and space as date/time separator is extremely trivial in terms of implementation and not much more time-consuming than writing a GitHub comment or raising an issue.

Note that changing anything TIME-element-related is not what Kent has proposed.

Btw, httparchive is probably not the same thing as the real internet.

cc @tantek

[cdumez]

FYI, WebKit is aligning with the specification (and Gecko) here, and supporting both 'T' and ' ' as separator.

[josepharhar]

I believe these are the related chrome bug and wpt:
https://wpt.fyi/results/html/semantics/forms/constraints/form-validation-validity-valueMissing.html
https://bugs.chromium.org/p/chromium/issues/detail?id=521871

FYI, WebKit is aligning with the specification (and Gecko) here, and supporting both 'T' and ' ' as separator.

If chrome is the odd one out, then I'd be happy to align it

[annevk]

Great, any final thoughts @zcorpan? I think this can be closed.

[josepharhar]

Once this lands, all browsers and the spec should match I think. I agree this issue can be closed.

[annevk]

Tentatively closing, @zcorpan can reopen as needed. Thanks @josepharhar!

[zcorpan]

So HTML is at least internally consistent, but JS is different.

@Marat-Tanalin

I don’t actually see what the real issue is. Supporting both T and space as date/time separator is extremely trivial in terms of implementation and not much more time-consuming than writing a GitHub comment or raising an issue.

The issue is not implementation complexity, but the cost for web developers having to learn and remember inconsistent rules in different parts of the web platform.