A text box that accepts "tomorrow at 3pm" and turns it into a real, unambiguous timestamp looks like a small feature. Underneath, it's solving a problem that's genuinely hard to get right, and easy to get subtly wrong in ways that only surface once a reminder fires at the wrong time.
Consider "next Friday," said on a Friday. Does that mean tomorrow-ish (the coming week) or eight days out (skip this Friday entirely)? Different people mean different things, and a parser has to pick a convention and be consistent about it — there's no universally correct answer.
"5/6" is another classic: May 6th or June 5th, depending entirely on which country wrote it. Free-text date parsing has to make locale assumptions somewhere, and every assumption is a place it can guess wrong for some fraction of users.
"Tomorrow" is only meaningful relative to *now*, and now has to be evaluated in the user's timezone, not the server's. A reminder created at 11pm Pacific but processed by a server running in UTC can compute "tomorrow" as the wrong calendar day entirely if the timezone isn't threaded through correctly — a bug that's invisible in testing (where the developer's timezone happens to match) and only shows up for real users in different timezones.
"Every Monday" is a recurrence pattern hiding inside what looks like a plain date phrase, and a parser handling free text needs to separately detect that from things like "next Monday" — one date, meant once, versus a rule meant to repeat indefinitely. Get this distinction wrong and a one-time reminder either repeats forever, or a recurring one never comes back after the first delivery.
Under the hood, this usually means scanning text for date-shaped fragments, classifying them (absolute date, relative date, time of day, recurrence marker), and resolving each against a reference point — "now, in this timezone" — using a chain of pattern-specific rules rather than one clever regex. Libraries like chrono-node exist specifically because this is enough surface area that most applications shouldn't write it from scratch.
No parser resolves every ambiguous phrase the way every user meant it, every time — that's not actually achievable, given that different people mean different things by the same phrase. The fix isn't chasing perfect parsing; it's surfacing what got parsed before the reminder is created, so a misread is caught in two seconds instead of discovered when the reminder fires at 3am instead of 3pm.
That's the reasoning behind showing a live "Due: Tuesday, September 3 at 9:00 AM" preview under a natural-language input as you type, rather than only after submitting — trust in the parsing comes from being able to verify it, not from the parser being flawless.