Skip to content

Stricter datetime validation #266

Open
@silverwind

Description

@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.

Activity

keithamus

keithamus commented on Jul 26, 2023

@keithamus
Member

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

silverwind commented on Jul 26, 2023

@silverwind
Author

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

silverwind commented on Jul 26, 2023

@silverwind
Author

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

keithamus commented on Jul 27, 2023

@keithamus
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

      Participants

      @silverwind@keithamus

      Issue actions

        Stricter `datetime` validation · Issue #266 · github/relative-time-element