Date Normalization Prompt Template

This prompt is for ETL developers and data engineers who need to convert free-text date expressions into a strict, machine-readable ISO 8601 format before ingestion into a data warehouse, event stream, or operational database. The core job is to take an unpredictable string like 'Jan 1st', 'next Tuesday', or 'Q4 2024' and produce a predictable output like 2024-01-01 with clear provenance. The ideal user is building a data pipeline where downstream systems—analytics dashboards, financial models, or scheduling services—will break if they receive non-standard date formats.

Use this prompt when the input text is unstructured and the date format is unknown in advance. It is designed for batch or streaming record normalization where each record must be processed independently. The prompt includes explicit instructions for handling relative dates by requiring a reference date, and it demands a confidence flag for ambiguous expressions like 'next Friday' when the reference date is unclear. Do not use this prompt for simple format casting where a deterministic parser like Python's dateutil would suffice; the model's strength is in resolving linguistic ambiguity, not in replacing a strptime call. Avoid using it for date arithmetic or scheduling logic—this prompt normalizes, it does not calculate intervals or recurrences.

Before wiring this into a production pipeline, ensure you have a clear contract for what happens when the model returns null or a low-confidence flag. The prompt is designed to surface uncertainty rather than guess silently, which means your application code must handle these cases—by routing to a manual review queue, applying a default, or rejecting the record. The next section provides the exact prompt template you can copy, adapt, and embed in your extraction harness.

This prompt template is the core instruction you send to the model for every date normalization task. It accepts a raw date string, optional context, and a set of constraints, then returns a structured JSON payload containing the normalized ISO 8601 date, the original source text, a confidence score, and a rationale. Use it as the foundation for your ETL pipeline's date normalization step.

textCopy
You are a date normalization engine. Your job is to convert free-text date expressions into ISO 8601 format (YYYY-MM-DD) with source annotation and confidence flags.

INPUT:
- raw_date: "[RAW_DATE_STRING]"
- context: "[CONTEXT]"
- reference_date: "[REFERENCE_DATE]"

OUTPUT_SCHEMA:
Return a single JSON object with these fields:
- normalized_date: string | null  // ISO 8601 YYYY-MM-DD, or null if no date found
- original_text: string           // the exact input substring that was interpreted
- confidence: "high" | "medium" | "low"
- rationale: string               // brief explanation of the normalization decision
- alternative_interpretations: string[]  // other plausible dates, if ambiguous

CONSTRAINTS:
- If the input contains no recognizable date, set normalized_date to null and confidence to "low".
- For relative expressions like "next Tuesday" or "tomorrow", use the reference_date to compute the absolute date.
- For quarter expressions like "Q4 2024", resolve to the first day of the quarter (2024-10-01) and note the quarter interpretation in the rationale.
- For ambiguous formats like "01/02/2024", prefer the locale hint in context if provided; otherwise flag as ambiguous and list alternatives.
- Do not hallucinate dates. If only a year is given ("2024"), return null with a rationale.
- Preserve the original text exactly as it appears in the input.

[EXAMPLES]

Input: raw_date="Jan 1st, 2024", context="", reference_date="2024-06-15"
Output: {"normalized_date":"2024-01-01","original_text":"Jan 1st, 2024","confidence":"high","rationale":"Standard month-day-year format with ordinal indicator removed.","alternative_interpretations":[]}

Input: raw_date="next Tuesday", context="email sent on Monday", reference_date="2024-06-17"
Output: {"normalized_date":"2024-06-25","original_text":"next Tuesday","confidence":"high","rationale":"From reference date Monday 2024-06-17, next Tuesday is 2024-06-25.","alternative_interpretations":[]}

Input: raw_date="Q4 2024", context="fiscal calendar", reference_date="2024-06-15"
Output: {"normalized_date":"2024-10-01","original_text":"Q4 2024","confidence":"medium","rationale":"Resolved to first day of Q4. If fiscal calendar differs, adjust reference_date context.","alternative_interpretations":["2024-10-01 (calendar Q4)","2024-11-01 (fiscal Q4 if offset)"]}

Input: raw_date="sometime next year", context="", reference_date="2024-06-15"
Output: {"normalized_date":null,"original_text":"sometime next year","confidence":"low","rationale":"Expression is too vague to resolve to a specific date.","alternative_interpretations":[]}

To adapt this template for your pipeline, replace the square-bracket placeholders with your actual values at runtime. The [RAW_DATE_STRING] is the free-text date you need to normalize. The [CONTEXT] field should carry any surrounding text, locale hints, or domain signals (e.g., "fiscal calendar", "US format") that help disambiguate the date. The [REFERENCE_DATE] must be today's date or the document's effective date in ISO 8601 format—this is critical for resolving relative expressions correctly. The [EXAMPLES] section can be expanded with domain-specific edge cases you encounter in your own data. If your downstream system requires a different output schema, modify the OUTPUT_SCHEMA block but keep the confidence and rationale fields to preserve auditability.

Before deploying this prompt into production, validate the output against a golden dataset of known date expressions and their expected ISO 8601 values. Pay special attention to locale-sensitive formats (MM/DD vs DD/MM), quarter boundaries, and relative date resolution around month and year transitions. For high-risk workflows such as financial reporting or legal document processing, route all low-confidence results to a human review queue and log the full prompt-response pair for audit.

The date normalization prompt is designed to sit inside a data ingestion or ETL pipeline where free-text date fields arrive from multiple upstream sources—web forms, CSV exports, legacy databases, or document extraction outputs. The prompt itself is stateless and expects a single input text plus optional context such as a reference date or locale hint. In production, you will typically wrap this prompt in a thin service or serverless function that accepts a batch of records, calls the LLM for each record (or in small batches if your provider supports it), and processes the structured JSON response. Because date normalization is deterministic in principle but ambiguous in practice, the implementation harness must handle three things well: input preparation, output validation, and ambiguous-case routing.

Input preparation starts with assembling the prompt variables. The [INPUT] placeholder should receive the raw date string exactly as it appears in the source field—do not pre-clean or trim unless your pipeline has a separate cleaning step with its own audit trail. The [REFERENCE_DATE] should default to the current date at ingestion time unless your use case requires a fixed reference (e.g., fiscal year boundaries). The [LOCALE_HINT] should be derived from a known field such as the user's country code, the document language, or a system configuration value; when unavailable, pass "unknown" and let the model flag ambiguity. The [OUTPUT_SCHEMA] placeholder should contain a compact JSON Schema or TypeScript interface definition that matches your downstream contract—at minimum, fields for normalized_date (ISO 8601 or null), confidence (a float between 0.0 and 1.0), resolution_notes (a short string explaining the normalization decision), and requires_review (boolean). The [CONSTRAINTS] placeholder should encode business rules such as acceptable date ranges, handling of future dates, and whether partial dates like "Q4 2024" should resolve to a start date, end date, or be rejected.

Output validation is critical because even well-structured prompts can produce malformed JSON, dates outside acceptable ranges, or confidence scores that don't match the resolution notes. After receiving the model response, run a validation layer that checks: (1) valid JSON parse, (2) presence of all required fields, (3) normalized_date is either null or a valid ISO 8601 string, (4) confidence is a number between 0 and 1, (5) requires_review is boolean, and (6) if requires_review is false but confidence is below your threshold (e.g., 0.85), flag the record anyway. On validation failure, implement a retry strategy: re-submit the same input with an error message appended to the prompt explaining what went wrong, up to a maximum of 2 retries. After the final retry, if validation still fails, route the record to a dead-letter queue or manual review bucket with the raw model output and validation errors attached. For high-throughput pipelines, consider using a cheaper/faster model for the initial pass and escalating to a more capable model only when confidence is low or validation fails—this is a model routing pattern that reduces cost while maintaining quality.

Logging and audit requirements for date normalization are often underestimated. Every normalization decision should produce an audit record containing: the raw input string, the reference date and locale hint used, the model ID and prompt version, the raw model response, the validated output, the retry count, and the final routing decision (accepted, sent to review, or dead-lettered). Store these audit records in a structured log system or database table that your data governance team can query. For regulated environments, ensure that human reviewers can see the original text alongside the normalized output and the model's resolution notes. The resolution_notes field in the output schema is your primary tool for explainability—instruct the model to be specific (e.g., "Resolved 'next Tuesday' relative to reference date 2025-01-15 as 2025-01-21") rather than vague ("Relative date resolved"). When building the review interface, display low-confidence records sorted by confidence score and allow reviewers to accept, override, or reject the normalization with a single click, feeding corrections back into your evaluation dataset for future prompt improvements.