July 22, 2025 at 9:24:33 PM UTC

	Since	posts	replies	likes	reposts and quotes	views
Bluesky	May 2023	1,039	8,236	23,127	2,380
Mastodon	Nov 2022	2,399	29,156	55,396	16,820
GitHub	Jul 2010	179	5,777 3,520	33,866	3,317
npm	Jul 2014	139	1,546			75,991,720
YouTube	Dec 2015	30		1,203		32,713
Letterboxd	Mar 2026	55
Blog	Nov 2025	20
Hacker News	Jan 2011	59	575	802
All	Jul 2010	4,807	37,967	114,394	22,517	76,024,433

In reply to Mastodon post

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

7 replies

Zach Leatherman 2 days later

I wrote this saga up in blog post form: https://fediverse.zachleat.com/@zachleat/114913999540366417
1. Cassey Lottman 2 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 2 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 2 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 2 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 2 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 2 days later
    
    @ardouglass (great question btw)