Sherlock

Sherlock's appeal is architectural rather than feature-count. Everything runs client-side, so the user's typed text never leaves the browser — a real advantage for scheduling fields inside privacy-sensitive apps, and it means no latency, no API quota, and no key management. The zero-dependency, sub-10KB footprint is the other differentiator: you can add natural language date entry to an existing product without pulling in a parsing framework or a calendar suite. What it does well is the common case. The demo page shows the intended inputs: "February 24 at 3pm - 2pm", "Vacation is in 4 weeks", "Christmas is on December 25th", "Homework 5 due next monday at 3pm", "Let's have lunch on the 3rd", "The retreat is from Jan 12 - 29", "Bake a cake tomorrow". That range — titled events, relative offsets, explicit ranges, recurring patterns, and holiday names — covers a lot of what a chat-like scheduling input actually receives. It also extracts the event title alongside the dates, which saves you a separate field. Where it stops is equally clear. It is rule-based, not an AI model, so ambiguous or unusual constructs are outside what it can reliably resolve, and the README-level scope is English event parsing rather than general date understanding. It does not manage a calendar for you; you still own storage, conflict detection, and reminders. Because the project is a single-maintainer open-source library, you should also weigh long-term maintenance against a funded alternative if scheduling is core to your product. For a lightweight helper inside a larger app, that trade is usually fine. For a product whose entire value is scheduling intelligence, a library this narrow will leave gaps you have to fill yourself.