5 date bugs your AI agent makes, and how to fix them

Ask a language model what date it will be "5 business days from now" and you'll get an answer quickly. Whether it's right depends on things the model can't see: which country's holidays apply, whether a weekend falls in between, and what today's date even is.

Models predict text. Date math needs a calendar, holiday data, time-zone rules and a clock. Here are five places where that gap turns into real bugs, with the correct answers computed deterministically.

1. Business days that ignore holidays

The question: a contract in the Philippines says payment is due 5 business days after December 22, 2026. When is that?

Counting weekdays gives December 29. But Christmas (December 25) and Rizal Day (December 30) are public holidays in the Philippines, so the correct answer is Thursday, December 31, 2026: the 23rd, the 24th, the 28th, the 29th and the 31st.

A model has to know both the holiday list for that country and year and apply it while counting. Holiday rules also change: observed days shift when a holiday falls on a weekend, and some dates are proclaimed each year.

{ "date": "2026-12-22", "business_days": 5, "country": "PH" }
→ { "result": "2026-12-31", "weekday": "Thursday", "is_business_day": true }

2. Times that don't exist

The question: schedule a job for 2:30 am on March 8, 2026 in New York.

That time never happens. At 2:00 am, clocks jump to 3:00 am for daylight saving time. Most systems silently shift the job to 3:30 am EDT, and some fail or run it at the wrong hour. The reverse problem happens in November, when 1:30 am occurs twice.

{ "timezone": "America/New_York", "datetime": "2026-03-08T02:30" }
→ { "status": "skipped", "resolved": "2026-03-08T03:30:00-04:00",
    "note": "This local time does not exist: clocks jump forward 60 minutes." }

If your agent books meetings, sets reminders or schedules cron jobs, it needs to check for this before it commits to a time.

3. Dates that mean two different things

The question: a CSV row says 03/04/2026. Is that March 4 or 3 April?

It depends on who wrote it: the US reads month first, most of the world reads day first. Nothing in the string tells you, so the right behavior is to flag it, not guess. The same goes for a bare number like 45000: as an Excel serial date it's March 15, 2023; as Unix seconds it's half a day after January 1, 1970.

{ "values": ["03/04/2026", 45000] }
→ "03/04/2026": 2026-03-04, ambiguous, alternative 2026-04-03 (day first)
→ 45000: 2023-03-15 (Excel serial), ambiguous, alternative 1970-01-01T12:30Z (Unix seconds)

When an agent cleans data, an ambiguity flag is worth more than a confident wrong answer.

4. Month-end billing that drifts

The question: a subscription started on January 31. When does it renew?

There's no February 31, so the first renewal is February 28. The common bug is computing each renewal from the previous one: February 28, then March 28, then April 28, and the customer's billing date has quietly moved. The correct approach measures every renewal from the original anchor: February 28, March 31, April 30, May 31.

{ "start": "2026-01-31", "interval": "month", "as_of": "2026-03-10" }
→ upcoming_renewals: ["2026-03-31", "2026-04-30", "2026-05-31"]

The same applies to cancel-by dates ("7 days before renewal") and prorated refunds, which depend on how many days the current period really has.

5. Rolling limits like Schengen 90/180

The question: a traveler was in the Schengen area from June 1 to July 15, 2026, and from September 10 to 30. How long can they stay if they enter again on November 1?

The rule allows 90 days in any rolling 180-day window, and both entry and exit days count. On October 1 they have used 66 days. Entering on November 1, they can stay 24 days, until November 24. A full 90-day stay is possible again from December 30, 2026.

This needs a day-by-day count over a sliding window, which is exactly the kind of arithmetic models approximate.

{ "trips": [{ "entry": "2026-06-01", "exit": "2026-07-15" }, { "entry": "2026-09-10", "exit": "2026-09-30" }],
  "date": "2026-10-01", "entry": "2026-11-01" }
→ { "days_used": 66, "max_stay": { "days_allowed": 24, "latest_exit": "2026-11-24" },
    "next_full_stay_date": "2026-12-30" }

The fix: let the agent call a tool

The pattern is the same in all five cases: don't ask the model to compute, give it a tool that does. With the Model Context Protocol (MCP), any compatible agent can discover and call these tools on its own.

I built Date Math for this: 20 deterministic date and time tools over MCP and HTTP, including everything above plus time-zone conversion, meeting slots across calendars, SLA countdowns, cron and RRULE schedules, and stock-market calendars. The first 25 calls a day are free with no signup, and a free current_time tool gives the model today's date.

To add it to Claude Code:

claude mcp add --transport http date-math https://date-math.datemath.workers.dev/mcp

Or in any MCP client config:

{ "mcpServers": { "date-math": { "url": "https://date-math.datemath.workers.dev/mcp" } } }

You can also try each tool in the browser on the landing page. The code is MIT licensed on GitHub.

What date problems do your agents still get wrong? I'd like to hear them. Appreciate your inputs!