Help

numcal accepts natural-language questions about dates and times. Type anything below. The eight chip groups on the home page are starting points, not limits.

What you can ask

Date and time formats

Dates can be written several ways. Pick whatever feels natural. If you're sharing a link with someone in another country, use a locale-prefixed page so the numeric date format isn't ambiguous on their end:

Locale-formatted home pages: en-US · en-GB · en-IN · en-CA · en-AU · de-DE · fr-FR · es-ES · it-IT · pt-BR · es-MX · ja-JP · en-NZ · en-ZA · en-IE

Number words

Numbers can be written as words from zero to ninety-nine, including compounds: six business days after Jun 1, twenty-five years ago, forty two days from today. a and an before a unit count as 1: a week ago.

The three rules

1. Order doesn't matter for differences. If you write between Dec 31 and Jan 1, the dates are silently reordered and the assumption row tells you so.
2. Countdowns are future-only; ages are past-only. Type until yesterday and you'll see a suggestion to use time since instead. Type age born tomorrow and you'll see a suggestion for days between.
3. Labels in countdowns are preserved. Type until my wedding 2027-09-12 and the URL becomes numcal.com/until?d=2027-09-12&label=my-wedding.

Why your answer is accurate

Every result shows its assumptions at the bottom of the card: calendar system, locale, working week, holidays applied, DST handling, year inference. If a date format is ambiguous, numcal picks a default and shows what it picked. You can screenshot a result and defend the number to a colleague.

How a query becomes a result

Each query goes through four passes. First, the text is normalized: lowercased, smart-quotes mapped to ASCII, twenty-five turned into 25, till into until. Second, an intent classifier matches the normalized text against a priority list of patterns — countdown, age, difference, weekday, time zone, and so on — and picks one. Third, an extractor for that intent reads out the dates, times, counts, and cities it needs. Fourth, the evaluator runs the math and produces the answer card with its assumption row.

Two consequences of this design. The same query, asked on the same day, returns the same answer down to the byte — no probabilities, no variation. And when a query doesn't match any pattern, numcal can be honest about it and suggest a near-match from the chip set instead of guessing.

Computed, not generated

No part of numcal calls a language model. There's no chatbot in the back of the calculator. The parser is a few hundred lines of pattern-matching TypeScript, and the math runs on the calendar primitives your browser already ships: Date, Intl.DateTimeFormat, and the ICU calendar systems for the non-Gregorian views. The whole answer pipeline runs in your browser; numcal's server doesn't see queries that parse successfully.

The practical upshot is that a numcal answer is defensible the way a hand-checked calendar calculation is defensible. There's no probability that someone else doing the same math gets a different number.

Privacy

numcal doesn't create accounts, doesn't drop cookies, and doesn't load third-party trackers. Pageview counts go to a self-hosted analytics instance (GoatCounter) which counts each visit without setting a cookie and without storing your IP. That is the entire telemetry stack.

One narrow exception: queries that don't parse are sent to a log endpoint so the parser can be improved on real misses rather than imagined ones. Stored: the text you typed, a timestamp, and a truncated User-Agent string for bot filtering. Not stored: your IP, any identifier, anything that ties one logged query to another. Each row is deleted automatically after 90 days. Queries that parse successfully aren't logged at all.

What numcal doesn't do (yet)

• Saved calculations or history (requires sign-in, coming with the Pro tier)
• Custom company holiday lists (also Pro)
• Hijri, Hebrew, Japanese-era calendars (v2)
• UI in languages other than English (v2; locale-aware date parsing already works)