Relative Date Normalization Prompt Template

This prompt is designed for RAG developers and search engineers who need to convert relative time expressions—such as 'last quarter', 'recent', or 'next month'—into explicit, machine-readable date ranges. The core job is to anchor a user's fuzzy temporal language to a concrete reference date, producing ISO 8601 boundaries that can be directly injected into metadata filters for vector databases, keyword search indexes, or hybrid retrieval pipelines. The ideal user is someone building a production retrieval system where time-sensitive corpora (financial filings, news archives, internal documents) require precise temporal scoping to avoid irrelevant results.

Use this prompt when your retrieval pipeline accepts natural language queries that contain relative dates and you need to transform those expressions into structured filter clauses before execution. It is particularly valuable in conversational RAG systems where follow-up questions like 'what about last week?' must resolve correctly against a session-level temporal anchor. However, do not use this prompt for simple date parsing tasks where a deterministic library like dateparser or python-dateutil would suffice. The prompt is warranted when the input language is ambiguous, context-dependent, or requires reasoning about fiscal calendars, partial periods, or domain-specific recency windows that rule-based systems handle poorly.

Before implementing this prompt, ensure you have a reliable reference date source—typically the current server time in UTC or a session-level anchor from the conversation context. The prompt will fail silently or produce incorrect ranges if the reference date is missing or stale. You should also define your target timezone and decide whether output ranges should be in UTC or a local timezone. For high-stakes applications like financial compliance or legal document retrieval, always pair this prompt with a validation step that checks for logical consistency (e.g., start dates before end dates, no future-dated constraints unless explicitly requested) and log the raw model output alongside the resolved ranges for auditability. If your use case involves fiscal calendars, holiday-aware date ranges, or multi-timezone normalization, consider the sibling prompts in this content group that handle those specific scenarios rather than overloading this single template.

This template is the core instruction set for normalizing relative date language. It accepts a user query containing temporal expressions, a reference date to anchor calculations, and optional constraints like a target timezone or fiscal calendar. The prompt instructs the model to output a structured JSON object with explicit start and end boundaries in ISO 8601 format, a confidence score, and a list of assumptions made during resolution. You can copy this template directly into your prompt management system, API call, or orchestration layer.

textCopy
You are a precise temporal reasoning engine. Your task is to convert relative time expressions in a user query into explicit ISO 8601 date ranges.

[INPUT]
User Query: [USER_QUERY]
Reference Date: [REFERENCE_DATE] (ISO 8601 date, e.g., 2025-04-08)
Target Timezone: [TARGET_TIMEZONE] (IANA timezone, e.g., America/New_York)
Fiscal Year Start: [FISCAL_YEAR_START_MONTH_DAY] (optional, e.g., 07-01 for July 1st)

[OUTPUT_SCHEMA]
Return a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "original_expression": "string (the extracted temporal phrase)",
  "start_date": "string (ISO 8601 date or datetime, YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS+HH:MM)",
  "end_date": "string (ISO 8601 date or datetime, exclusive end boundary)",
  "confidence": "number (0.0 to 1.0)",
  "assumptions": ["string (list of explicit assumptions made during resolution)"],
  "alternative_ranges": [
    {
      "start_date": "string",
      "end_date": "string",
      "rationale": "string (why this alternative exists)"
    }
  ]
}

[CONSTRAINTS]
1. Always use the provided Reference Date as the anchor for relative calculations.
2. If the Target Timezone is provided, all datetime boundaries must be in that timezone and include the UTC offset.
3. For fiscal quarter references (e.g., 'Q3'), use the Fiscal Year Start if provided; otherwise, assume a calendar year and note this in assumptions.
4. For vague terms like 'recent' or 'latest', provide a primary range and at least one alternative range with a rationale.
5. If the temporal expression is ambiguous or cannot be resolved with high confidence (confidence < 0.7), still provide the best estimate but flag the ambiguity in assumptions.
6. If no temporal expression is found, return null for start_date and end_date and set confidence to 0.0.
7. Handle month-end rollover correctly (e.g., 'last month' on March 31st should resolve to the full month of February).
8. For 'next [day of week]', calculate the correct upcoming occurrence from the Reference Date.

[EXAMPLES]
Example 1:
User Query: "Show me sales from last quarter"
Reference Date: 2025-04-08
Target Timezone: America/Chicago
Fiscal Year Start: null
Output:
{
  "original_expression": "last quarter",
  "start_date": "2025-01-01T00:00:00-06:00",
  "end_date": "2025-04-01T00:00:00-05:00",
  "confidence": 0.95,
  "assumptions": ["Calendar year quarters assumed since no fiscal year start provided."],
  "alternative_ranges": []
}

Example 2:
User Query: "What were the recent support tickets about?"
Reference Date: 2025-04-08
Target Timezone: UTC
Fiscal Year Start: null
Output:
{
  "original_expression": "recent",
  "start_date": "2025-03-25T00:00:00Z",
  "end_date": "2025-04-08T00:00:00Z",
  "confidence": 0.6,
  "assumptions": ["'Recent' interpreted as a 14-day window, a common default for support contexts."],
  "alternative_ranges": [
    {
      "start_date": "2025-04-01T00:00:00Z",
      "end_date": "2025-04-08T00:00:00Z",
      "rationale": "Alternative interpretation: 'recent' could mean the last 7 days."
    },
    {
      "start_date": "2025-03-08T00:00:00Z",
      "end_date": "2025-04-08T00:00:00Z",
      "rationale": "Alternative interpretation: 'recent' could mean the last 30 days."
    }
  ]
}

To adapt this template, replace the square-bracket placeholders with your application's runtime values. The [USER_QUERY] and [REFERENCE_DATE] are mandatory; [TARGET_TIMEZONE] and [FISCAL_YEAR_START_MONTH_DAY] are optional but critical for accuracy in global or financial applications. If your retrieval system expects Unix timestamps or a different date format, modify the [OUTPUT_SCHEMA] description accordingly. The [EXAMPLES] section is crucial for few-shot behavior—add at least two more examples that reflect your domain's common temporal expressions and edge cases. For production, consider moving the output schema into your application's JSON mode or function-calling tool definition to guarantee structural validity, and use the prompt's confidence field to trigger a clarification workflow when it falls below a threshold like 0.7.

This prompt is designed to sit immediately before your retrieval step in a RAG pipeline. It takes a raw user query and a reference timestamp, normalizes all relative time expressions into explicit ISO 8601 date ranges, and returns structured boundaries that your application can convert directly into metadata filter clauses for vector databases, search indexes, or SQL WHERE statements. The prompt is stateless by design—every call must receive a fresh reference date, which makes it safe to deploy behind a stateless API endpoint or as a pre-processing step in a queue-based retrieval worker.

The implementation should enforce a strict contract around the reference date. Always inject the current server timestamp as [REFERENCE_TIMESTAMP] in ISO 8601 format with an explicit UTC offset (e.g., 2025-03-15T14:30:00+00:00). If your application supports user-level timezone preferences, resolve the reference date to the user's local timezone before passing it to the prompt. For session-based conversational RAG, store the conversation start time as the anchor and reuse it across all turns in that session to prevent temporal drift. Validate the model's output against a JSON schema that requires start_date and end_date fields in ISO 8601 format, an expression_type enum (e.g., relative_range, absolute_range, open_ended), and a confidence float between 0.0 and 1.0. Reject any response that fails schema validation and retry once with a stronger constraint instruction before falling back to a default 30-day window.

Log every normalization result alongside the original query, the reference timestamp, and the model version for debugging and eval. Common failure modes include the model defaulting to calendar-year boundaries when the user meant a fiscal year, misinterpreting 'last' as 'previous completed period' vs. 'trailing N days', and mishandling month-end rollover for dates like January 31st when adding a month. Build a small eval harness with 20-30 edge cases covering these scenarios, and run it against every prompt or model change before deployment. For high-stakes financial or legal retrieval, route low-confidence outputs (confidence < 0.85) to a human review queue or a secondary clarification prompt before executing the retrieval. This prompt is a pre-retrieval transform, not a retrieval strategy—pair it with your existing hybrid search or vector database query builder to convert the normalized boundaries into the filter syntax your backend expects.