Repository navigation
Stricter datetime validation #266
Description
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.
Activity
keithamus commentedon Jul 26, 2023
This is a good idea. Additionally I think we can afford to start with a
console.warnand then throw a RangeError for a breaking release. Down with non-iso8601 dates!silverwind commentedon Jul 26, 2023
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 commentedon Jul 26, 2023
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.
keithamus commentedon Jul 27, 2023
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.
ryux1 commentedon Sep 7, 2026
I am working on this against current main. I will add a warning when a non-empty
datetimevalue is outside the ECMAScript date-time string format, keep parsing behavior backward-compatible for this release, and add focused tests for valid ISO timestamps and browser-dependent inputs.