Stricter `datetime` validation

[silverwind]

The docs about the datetime attribute say:

This must be a valid ISO8601 DateTime

This statement is incorrect. Any value that can be passed to the Date constructor will work which presents a cross-browser issue because JS engines are inconsistent in which formats their Date constructor accept.

For example, the golang default string representation only parses in v8:

$ eshost -e "new Date('2009-11-10 23:00:00+00:00 UTC')"
#### JavaScriptCore
Invalid Date

#### spidermonkey
Invalid Date

#### v8
Wed Nov 11 2009 00:00:00 GMT+0100 (Central European Standard Time)

Also try this fiddle in multiple browsers.

How about adding an option attribute to pass in a validation regex into the element to validate the passed dates, when present? This would at least not make this issue missable by developers who only test in Chrome.

[Keith Cirkel]

This is a good idea. Additionally I think we can afford to start with a console.warn and then throw a RangeError for a breaking release. Down with non-iso8601 dates!

[silverwind]

If we validate for the specced Date Time String Format, which every JS engine is guaranteed to support, it would be ideal. It should be a pretty trivial regex.

[silverwind]

As for errors, I would prefer something that can be caught in window.onerror, console logging is easier to miss, but it might serve as a start to help people migrate to the proper format.

[Keith Cirkel]

I concur but an error would be a breaking change. I’d like for our breaking changes to have a lead up so IMO a console warn should happen in a minor first.