Content-Length: 256789 | pFad | http://github.com/github/relative-time-element/issues/266

5B Stricter `datetime` validation · Issue #266 · github/relative-time-element · GitHub
Skip to content

Stricter datetime validation #266

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
silverwind opened this issue Jul 26, 2023 · 4 comments
Open

Stricter datetime validation #266

silverwind opened this issue Jul 26, 2023 · 4 comments
Labels
enhancement help wanted

Comments

@silverwind
Copy link

silverwind commented Jul 26, 2023 •
edited
Loading

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.
@silverwind silverwind mentioned this issue Jul 26, 2023
Merged
@keithamus
Copy link
Contributor

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
Copy link
Author

silverwind commented Jul 26, 2023 •
edited
Loading

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
Copy link
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
Copy link
Contributor

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
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@silverwind @keithamus








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://github.com/github/relative-time-element/issues/266

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy