I really tried to avoid this one but unfortunately this is now something I maintain 😭 https://github.com/11ty/parse-date-strings
24 replies
@zachleat A bit late to this, am I’m not sure if it would solve for every string, but I’ve been happy with https://tempo.formkit.com/
@d3v1an7 that one looks decent! It’s about 1MB on disk but looks like it doesn’t support week date or day of year formats either
One more entry in my epic date parsing adventure. I’ve shipped a breaking change to this library to ensure that all valid date strings supported in Eleventy v4 will be RFC 9557-compatible, ensuring friendliness with the standardized Temporal APIs coming to a JavaScript runtime near you. Our full test suite runs against both!
Read (a little) more: https://github.com/11ty/parse-date-strings/releases/tag/v2.0.0
I wrote this saga up in blog post form: https://fediverse.zachleat.com/@zachleat/114913999540366417
@zachleat I have that deep feeling of dread like I'm watching a horror movie and you can tell the scary part is about to start
@cassey I’ve just heard a noise in the basement and I’m just going in to investigate by myself without a flashlight
@zachleat I saw the temporal polyfills as things to check out. Do you have a quick answer as to why you didn’t use one of those if Temporal compatibility is the end goal?
For context where my mind is at, my date fields are Temporal ZonedDateTime strings so I’m currently making use of addDateParsing.
@ardouglass I think if I started the process over again with what I know now I probably would have used one of those! I would probably even recommend other folks use those instead too.
Even more so when tree shaking lands in that smaller polyfill too: https://www.npmjs.com/package/temporal-polyfill#tree-shakable-api
At the start I wanted more ISO8601 compat (you can see that in parse-date-strings@1) but realized more strict parsing/breaking changes now was preferable to the same breaking changes later (parse-date-strings@2)
@ardouglass so basically, I had the library and test suite already ready, just needed to make some small changes in the library for RFC 9557 compat (and to save ~55KB over the full Temporal polyfill lib)
@ardouglass (great question btw)
@zachleat will temporal solve this once it is finalized?
@cbirdsong Temporal seems to use RFC 9557 which is a much stricter date format https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Instant#rfc_9557_format
so, we could absolutely support that one too but it doesn’t really solve a problem 😓
@cbirdsong I ended up doing a pivot after you asked this question — so I appreciate you asking it!
@zachleat glad to be of service 🫡
@zachleat Would you accept a PR that rips out vitest in favor of Node’s built-in test and assert libraries? 😂
(I’m mostly serious but would also accept being told to pound sand.)
@zachleat dates and times sucks. My sympathies
@mikehoss appreciate your support in this trying time
@zachleat oh Zach I’m so sorry
@tylersticka in lieu of flowers please donate to PBS
@zachleat oh no, i'm so sorry. i don't think most people understand how difficult this is.
anyways, it's been nice knowing you
@grigs please keep me in your thoughts in these trying times