Conversation
✅ Deploy Preview for guileless-rolypoly-866f8a ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
| datetimeOffset.parse("2020-10-14T17:42:29+00:00"); | ||
| datetimeOffset.parse("2020-10-14T17:42:29+03:15"); | ||
| datetimeOffset.parse("2020-10-14T17:42:29+0315"); | ||
| datetimeOffset.parse("2020-10-14T17:42:29+03"); |
There was a problem hiding this comment.
These aren't parseable by new Date().
|
I've been discussing using Zod at work and whilst one of my collegues was doing a proof of concept, he noticed is was accepting dates such as the 99th of June. Looked at the code and realised it was just doing some regex. Whilst this was good start as it checks the format, it doesn't cover a number of scenarios including the one mentioned above. @samchungy - your work is still an improvement but there are some cases that you are missing. For example it will accept a the 29th of Febuary 2021 even though this is not a valid year. Also I don't think that the day will validate for the correct months. I.e. if you put the 31st September then the validaiton will not fail when it should |
Co-authored-by: Peter Robertson <peterjdrb@outlook.com>
Hey mate, I went a slightly different approach but I stole some of your test cases |
|
Okay, I've rolled back that PR you mentioned @samchungy. Good catch. All successful results should definitely be parsable by As for this particular PR, it's much slower in Node.js than the regex-based approach. I added a benchmark in 35f0a38 that can be run with $ yarn benchmark --datetime
yarn run v1.22.19
warning ../../../package.json: No license field
$ tsx src/benchmarks/index.ts --datetime
datetime: new Date() x 7,195,365 ops/sec ±1.23% (96 runs sampled)
datetime: regex validation x 29,761,251 ops/sec ±0.42% (96 runs sampled)
datetime: simple regex with validation x 6,113,522 ops/sec ±0.66% (97 runs sampled)Given that I'm inclined to stick with regex. But Sam if you see any glaring issues with that benchmark let me know 👍 |
Oooo yeah that is a significant degradation. Let me cook something up and see if I can make it better |
|
Latest master covers all of my new test cases so I'm going to close this. |
3 participants
Resolves #2357
I think this change makes sense. If your JS system using Zod is going to process a datetime string, it will likely use
new Date()to process it at some point in the system, just maybe not right now. So we should validate thatnew Date()works on it to get rid of things like invalid months, invalid days, invalid seconds etc.However, this change is technically a small breaking change as #1797 (comment) introduced a date time format which
new Date()does not accept which seems like a strange addition. I would suggest that users using that format should use a custom regex to validate instead as I will assume the majority of users would not be using that format.