10 replies

1. d3v1an7 4 hr later

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

   1. Zach Leatherman 15 hr later

      @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

2. Zach Leatherman 23 hr later

   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

   1. Zach Leatherman 3 days later

      I wrote this saga up in blog post form: https://fediverse.zachleat.com/@zachleat/114913999540366417

      1. Cassey Lottman 3 days later

         @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

         1. Zach Leatherman 3 days later

            @cassey I’ve just heard a noise in the basement and I’m just going in to investigate by myself without a flashlight

      2. Andrew Douglass 3 days later

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

         1. Zach Leatherman 3 days later

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

            1. Zach Leatherman 3 days later

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

         2. Zach Leatherman 3 days later

            @ardouglass (great question btw)