Relative Date Expression Resolution Prompt

This prompt is designed for scheduling system builders, log processors, and data pipeline engineers who need to convert natural language relative date expressions—such as 'next Friday', 'end of month', or '2 weeks ago'—into absolute, machine-readable dates. The core job-to-be-done is to take a user-provided or system-extracted relative expression and an anchor timestamp, then produce a resolved date, the interpretation rule applied, and a confidence indicator. This is a critical normalization step before temporal data enters databases, reporting pipelines, or scheduling engines where ambiguity breaks downstream queries and comparisons.

Use this prompt when your application accepts flexible date input from users, parses temporal expressions from unstructured text, or needs to resolve relative deadlines in workflow automation. The required inputs are a relative date expression string and an anchor timestamp (defaulting to the current time if not provided). The expected output is a structured object containing the resolved ISO 8601 date, the anchor used, the interpretation rule applied, and a confidence score. Do not use this prompt for simple timestamp format conversion (use the ISO 8601 Normalization prompt instead), for disambiguating MM/DD vs DD/MM formats (use the Ambiguous Date Disambiguation prompt), or for extracting dates from free-text documents (use the Timestamp Extraction prompt). This prompt is specifically for the resolution step where the expression is already isolated and needs to be converted.

The primary risks in production are ambiguity in expressions like 'next Friday' when the anchor is already a Friday, month-boundary edge cases for expressions like 'end of month' or 'last day of February', and locale-specific interpretations of 'next' vs 'this'. Your implementation must include a validation layer that checks the resolved date against the anchor for logical consistency (e.g., 'next Friday' must be in the future relative to the anchor). For high-stakes scheduling or billing systems, require human review when the confidence score falls below a defined threshold. Before deploying, test against a golden dataset of expression-anchor pairs with known resolutions, paying special attention to DST transitions, leap years, and month boundaries.

This prompt template converts natural-language relative date expressions like 'next Friday', 'end of month', or '2 weeks ago' into absolute dates. It requires an anchor timestamp to serve as the reference point for resolution, and it returns not only the resolved date but also the interpretation rule applied—making the resolution auditable and debuggable. Use this template when your scheduling system, log processor, or reporting pipeline receives human-entered date expressions that must be normalized before downstream queries or comparisons.

textCopy
You are a temporal expression resolver. Your job is to convert relative date expressions into absolute dates given an anchor timestamp.

[INPUT]
Relative date expression: [RELATIVE_EXPRESSION]
Anchor timestamp (ISO 8601): [ANCHOR_TIMESTAMP]
Timezone context: [TIMEZONE]

[CONSTRAINTS]
1. Resolve the expression relative to the anchor timestamp in the given timezone.
2. Return the resolved date in ISO 8601 format (YYYY-MM-DD).
3. Explain the interpretation rule you applied in plain language.
4. If the expression is ambiguous, list the possible interpretations and explain which one you chose and why.
5. If the expression cannot be resolved, return an error with the reason.
6. Do not invent dates beyond what the expression and anchor support.

[OUTPUT_SCHEMA]
{
  "resolved_date": "YYYY-MM-DD",
  "anchor_used": "[ANCHOR_TIMESTAMP]",
  "interpretation_rule": "string explaining the rule applied",
  "ambiguities": ["string describing each ambiguity if any"],
  "confidence": "high|medium|low",
  "error": null or "error message if unresolvable"
}

[EXAMPLES]
Expression: "next Friday"
Anchor: "2025-03-10T14:00:00-04:00" (Monday)
Output: {"resolved_date": "2025-03-14", "anchor_used": "2025-03-10T14:00:00-04:00", "interpretation_rule": "'Next Friday' from Monday March 10 resolves to the upcoming Friday March 14 in the same week.", "ambiguities": [], "confidence": "high", "error": null}

Expression: "end of month"
Anchor: "2025-01-15T09:00:00Z"
Output: {"resolved_date": "2025-01-31", "anchor_used": "2025-01-15T09:00:00Z", "interpretation_rule": "'End of month' from January 15 resolves to January 31, the last calendar day of the current month.", "ambiguities": [], "confidence": "high", "error": null}

Expression: "2 weeks ago"
Anchor: "2025-04-20T12:00:00+00:00"
Output: {"resolved_date": "2025-04-06", "anchor_used": "2025-04-20T12:00:00+00:00", "interpretation_rule": "'2 weeks ago' from April 20 subtracts 14 calendar days, landing on April 6.", "ambiguities": [], "confidence": "high", "error": null}

Expression: "next month"
Anchor: "2025-01-31T00:00:00Z"
Output: {"resolved_date": "2025-02-28", "anchor_used": "2025-01-31T00:00:00Z", "interpretation_rule": "'Next month' from January 31 resolves to February 28, the last day of the following month, since February does not have 31 days.", "ambiguities": ["'Next month' could mean February 28 (same day-of-month clamped) or March 3 (adding 31 days). Chose calendar-month interpretation."], "confidence": "medium", "error": null}

Adapt this template by replacing the placeholders with your application's actual values. The [RELATIVE_EXPRESSION] comes from user input or upstream systems. The [ANCHOR_TIMESTAMP] should be the current time or a relevant reference point from your system. The [TIMEZONE] field is critical for expressions like 'tomorrow' or 'next business day' where the date boundary depends on the local timezone. For production use, wrap this prompt in a validation layer that checks the output schema, verifies the resolved date is within expected bounds, and logs any low-confidence or ambiguous resolutions for human review. Test this prompt against month-boundary edge cases, leap years, DST transitions, and locale-specific expressions like 'fortnight' or 'biweekly' before deployment.

This prompt is designed to be called as a deterministic resolution step within a larger application pipeline, not as a free-form chat interface. The primary integration pattern is a synchronous API call where the application provides the relative expression, an anchor timestamp, and optional context (timezone, holidays, business rules), and expects a structured JSON response containing the resolved absolute date, the interpretation rule applied, and a confidence flag. The prompt should be treated as a stateless function: given the same inputs, it must produce the same resolution. Do not rely on model memory of prior calls.

Input contract: The application must supply [RELATIVE_EXPRESSION] (the string to resolve), [ANCHOR_TIMESTAMP] (an ISO 8601 timestamp representing 'now' or the reference point), [TIMEZONE] (IANA timezone string like America/Chicago), and optionally [HOLIDAY_CALENDAR] (a list of non-business days) and [BUSINESS_RULES] (e.g., 'next business day means next weekday that is not a holiday'). Output contract: The model must return a JSON object with resolved_date (ISO 8601 date string), anchor_used (the anchor timestamp provided), interpretation (a human-readable explanation of the rule applied), and confidence (a value of high, medium, or low). Validation layer: Before the resolved date enters any downstream system (booking engine, report query, audit log), the application must validate that resolved_date is a parseable date, that confidence is not low without explicit handling, and that the date falls within an acceptable operational window (e.g., not more than 1 year in the past or 5 years in the future unless the use case permits it).

Retry and fallback logic: If the model returns malformed JSON, a missing resolved_date, or a confidence of low, the application should retry once with a simplified version of the prompt that removes optional context and asks for only the most likely resolution. If the retry also fails or returns low confidence, the system should escalate to a human review queue rather than silently defaulting to a potentially incorrect date. For high-throughput pipelines where human review is impractical, implement a safe default (e.g., treat 'next Friday' as the upcoming Friday from the anchor date using a deterministic library like dateutil or moment-business-days) and log the mismatch for later analysis. Model choice: This task benefits from models with strong reasoning and instruction-following, such as Claude 3.5 Sonnet or GPT-4o. Avoid smaller or older models that may hallucinate date arithmetic. Observability: Log every resolution with the input expression, anchor, resolved date, confidence, and model version. This audit trail is critical for debugging scheduling errors and for compliance in regulated environments where date calculations affect deadlines, billing, or legal obligations.

Tool use and RAG considerations: For most implementations, this prompt does not require external tools or retrieval. The model can perform the date arithmetic internally. However, if your [HOLIDAY_CALENDAR] is large or changes frequently, consider injecting it via a retrieval step before the prompt call rather than hardcoding it. For recurring resolution needs (e.g., resolving 'next business day' for thousands of records), batch the calls and consider caching results for identical expression-anchor pairs to reduce latency and cost. What to avoid: Do not use this prompt for resolving dates in user-facing chat without first validating the output. Do not pass the resolved date directly into financial transactions, legal deadlines, or medical scheduling without human confirmation when confidence is anything other than high. The prompt resolves linguistic ambiguity, but the application owns the business risk.