Date-Time and ISO 8601 Compliance Prompt

This prompt is designed for a single, high-stakes job: auditing a structured or semi-structured AI-generated output to verify that every date, time, and timestamp field strictly conforms to ISO 8601. The ideal user is a backend engineer, data pipeline owner, or platform developer who is ingesting LLM outputs into a system with rigid temporal parsing requirements—such as a SQL database with TIMESTAMPTZ columns, a logging pipeline, or an API that rejects non-compliant date strings. The prompt is not a general-purpose date formatter or a conversational helper; it is a programmatic evaluation gate that produces a machine-readable audit report. You should use this prompt when format inconsistency in temporal data is a known failure mode that breaks downstream parsers, causes silent data corruption, or forces manual cleanup of AI-generated records.

The prompt requires a clear [INPUT] containing the target text or structured object to audit, and an optional [FIELD_MAP] that tells the judge which keys or paths to inspect. It is designed to be run as a pre-ingestion validation step, not as a post-hoc repair tool. The output is a field-level compliance report that flags specific violations: missing timezone offsets, ambiguous date formats (e.g., 02/03/2025), invalid calendar values (e.g., February 30th), and non-ISO 8601 representations like Jan 1, 2025. The prompt includes explicit checks for common LLM temporal hallucinations, such as inventing dates that do not exist or generating timestamps with impossible hour values. This is not a prompt for human-readable summaries; it is a deterministic-style audit that should be paired with a JSON Schema validator on the output to ensure the report itself is parseable.

Do not use this prompt when you need to normalize or repair malformed dates—that is a separate repair workflow. Do not use it for natural-language date reasoning (e.g., 'next Tuesday') unless you have already resolved those expressions to concrete dates upstream. The prompt assumes that the input text already contains date strings that should be ISO 8601 compliant, and its job is to find the ones that are not. For high-risk domains such as healthcare records, financial transactions, or legal documents, always route violations to human review before ingestion. The audit report is an advisory signal, not a source of truth. Wire this prompt into your pipeline before data hits your database, and treat a non-zero violation count as a hard stop or a quarantine flag.

This prompt template is designed to be dropped into an evaluation harness that checks LLM outputs for temporal data integrity. It is not a general-purpose date parser; it is a compliance auditor that produces a structured, field-level report. Use it when downstream systems will reject or misinterpret malformed date-time strings, such as in API payloads, database ingestion, or log processing pipelines. The prompt expects a list of date-time strings and an optional context about the expected granularity (e.g., 'date-only', 'datetime-with-timezone').

textCopy
You are a strict ISO 8601 compliance auditor. Your task is to validate a list of date-time strings against the ISO 8601 standard, check for timezone presence, and flag impossible calendar dates.

[INPUT]
A JSON array of objects, each with a "field_name" and a "value" (the date-time string to audit).
Example:
[
  {"field_name": "created_at", "value": "2024-02-30T14:00:00Z"},
  {"field_name": "updated_at", "value": "2024-03-15"}
]

[CONTEXT]
Expected granularity: [GRANULARITY]
- Options: "date-only", "datetime-local", "datetime-with-timezone", "any-iso8601"
- If "datetime-with-timezone", flag any value missing a timezone offset or 'Z'.

[OUTPUT_SCHEMA]
Return a JSON object with a single key "audit_results", which is an array of objects. Each object must have the following keys:
- "field_name": (string) the original field name from the input.
- "original_value": (string) the original value provided.
- "is_valid_iso8601": (boolean) true if the string is syntactically valid ISO 8601.
- "has_timezone": (boolean) true if the value includes a timezone designator (Z, ±HH:MM, ±HHMM, ±HH).
- "is_valid_calendar_date": (boolean) true if the year-month-day combination is a real date on the Gregorian calendar.
- "issues": (array of strings) a list of human-readable descriptions of any problems found. Empty array if no issues.

[CONSTRAINTS]
- Do not attempt to correct or normalize the values. Only audit and report.
- Treat February 30th, April 31st, and similar impossible dates as invalid calendar dates.
- A missing timezone is only an issue if [GRANULARITY] is "datetime-with-timezone".
- If a string is not valid ISO 8601 at all, set "is_valid_calendar_date" and "has_timezone" to false.

To adapt this template, replace the [GRANULARITY] placeholder with the specific requirement for your pipeline. For strict API contracts, use "datetime-with-timezone". For user-facing date pickers, "date-only" may be sufficient. The output schema is designed to be machine-readable for automated pass/fail gating in a CI/CD pipeline. For high-risk domains like finance or healthcare, always route outputs with is_valid_iso8601: false or is_valid_calendar_date: false to a human review queue before ingestion, as a malformed date can represent a material data integrity error. The next step is to wire this prompt into a test harness with known failure cases like "2024-02-30" and "2024-13-01" to verify the judge's calibration before relying on it in production.

This prompt is designed to operate as a post-generation validation step, not a real-time correction layer. The typical integration pattern places it after an LLM generates structured output containing temporal fields and before that output reaches a downstream parser, database, or API. The harness should receive the raw LLM output, extract all date-time fields (either by schema mapping or by scanning for ISO 8601 patterns), and submit each field to the prompt for audit. The prompt returns a field-level compliance report that your application code can act on: pass the record through, flag it for repair, or escalate for human review.

Validation and retry logic should be implemented in the application layer, not inside the prompt. After receiving the audit report, check for is_compliant: false on any field. For non-critical fields with minor issues (e.g., missing timezone offset where UTC is implied by business rules), apply a normalization function in code rather than asking the LLM to fix it—this avoids introducing new hallucinations. For critical fields with invalid calendar dates (e.g., February 30th) or unparseable strings, implement a single retry by feeding the audit report back to the original generation prompt with a correction instruction. If the retry also fails, route the record to a human review queue with the audit report attached. Log every audit result with the field path, the original value, the compliance verdict, and the specific violation code (invalid_calendar_date, missing_timezone, non_iso_format, ambiguous_offset) for downstream monitoring.

Model choice matters for this prompt. Use a model with strong instruction-following and low hallucination rates for structured audit tasks—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may themselves hallucinate calendar validity or timezone rules. Set temperature=0 to maximize deterministic audit behavior. If you are processing high volumes, batch multiple date-time fields into a single prompt call with clear field-path labels to reduce API overhead, but keep batches under 20 fields to avoid attention dilution. For streaming or real-time systems, implement a circuit breaker: if the audit prompt fails or times out, apply a conservative default (reject the record or mark it for review) rather than passing potentially malformed dates downstream.

Testing and evaluation should use a golden dataset of known-valid and known-invalid date-time strings. Include edge cases that LLMs commonly mishandle: February 29 in non-leap years, 24:00:00 vs. 00:00:00 next-day representations, timezone offsets like +14:00 (valid in ISO 8601 but rare), and dates before 1582 (the Gregorian calendar switch). Measure both false-positive rate (flagging valid dates as non-compliant) and false-negative rate (missing genuinely invalid dates). Run this eval suite whenever you change the prompt, the model, or the model version. If your application operates in a regulated domain (finance, healthcare, legal), require that any record with a date-time compliance failure is reviewed by a human before it affects a transaction, record, or patient outcome.