Timestamp Normalization Across Time Zones Prompt

This prompt is designed for distributed system operators, data engineers, and backend developers who must reconcile timestamp data originating from multiple time zones into a single, consistent format. The core job-to-be-done is taking a batch of timestamps—often from logs, databases, or user-generated events—and normalizing them to a configurable target time zone (such as UTC) while preserving the original source time zone for auditability. The ideal user has a list of ISO 8601 or similarly formatted timestamps and needs a reliable, automated way to handle Daylight Saving Time (DST) transitions, detect ambiguous or impossible times, and produce a clean, machine-readable output payload for downstream ingestion.

Use this prompt when you have a high volume of timestamps that need programmatic normalization and you cannot rely on a single application-layer library due to language or deployment constraints. It is particularly effective when timestamps arrive with explicit UTC offsets, IANA time zone identifiers (like 'America/New_York'), or abbreviated codes that require disambiguation. The prompt is designed to be wired into a data pipeline where the output is validated against a strict schema before being written to a database or passed to another service. You should not use this prompt for real-time, sub-millisecond latency requirements or for converting relative time expressions like 'yesterday' or 'next Tuesday'; those require a different temporal reasoning approach. For high-risk financial or healthcare applications, always pair this prompt with a post-processing validation step that checks for off-by-one-hour DST errors and flags any timestamp that could not be resolved with high confidence.

Before integrating this prompt, ensure you have a clear target time zone, a defined policy for handling ambiguous timestamps (such as choosing the earlier or later instance during a DST fall-back transition), and a list of acceptable source time zone formats. The prompt will return a structured JSON array with the original timestamp, the normalized timestamp, the resolved UTC offset, and a confidence flag. If your use case involves timestamps without any time zone information, you must either reject them or provide a default assumption in the [CONTEXT] block. The next step is to copy the prompt template, configure your placeholders, and run it against a small test set of known DST edge cases before deploying it into your production pipeline.

This prompt template is designed to be copied directly into your AI harness, test suite, or orchestration layer. It accepts a list of timestamps in heterogeneous formats and time zones, then normalizes them to a configurable target timezone (defaulting to UTC) while preserving the original source timezone for auditability. The prompt handles Daylight Saving Time (DST) transitions, detects ambiguous timestamps (e.g., repeated hours during fall-back transitions), and flags inputs that cannot be reliably resolved. Use this template when you need a repeatable, schema-conformant normalization step before timestamps enter your database, log aggregator, or analytics pipeline.

textCopy
You are a timestamp normalization engine. Your task is to convert a list of input timestamps into a consistent, machine-readable format.

## INPUT
[INPUT]

## TARGET TIMEZONE
[TARGET_TIMEZONE]

## OUTPUT SCHEMA
Return a JSON object with a single key "normalized_timestamps" containing an array of objects. Each object must have the following fields:
- "input_index": integer (0-based index matching the input order)
- "original_value": string (the exact input string provided)
- "source_timezone": string or null (IANA timezone name detected from the input, or null if no timezone was specified)
- "normalized_utc": string (ISO 8601 timestamp in UTC, e.g., "2024-03-15T14:30:00Z")
- "normalized_target": string (ISO 8601 timestamp converted to [TARGET_TIMEZONE])
- "is_dst_ambiguous": boolean (true if the timestamp falls within a DST transition ambiguity window)
- "resolution_notes": string or null (explain how ambiguity was resolved, or null if unambiguous)

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RULES
1. If an input timestamp does not specify a timezone, treat it as already in [TARGET_TIMEZONE].
2. For timestamps that fall within a DST "fall-back" overlap (e.g., 01:30 AM occurs twice), set "is_dst_ambiguous" to true and default to the earlier occurrence (standard time) unless [CONSTRAINTS] specifies otherwise.
3. If an input cannot be parsed as a valid timestamp, include it in the output array with "normalized_utc" and "normalized_target" set to null, and "resolution_notes" set to "PARSE_ERROR: <reason>".
4. Preserve the original input string exactly in "original_value"—do not trim or modify it.
5. Do not invent timezones. If the input contains a non-IANA timezone abbreviation (e.g., "EST", "IST"), resolve it using the most common IANA mapping and note the mapping in "resolution_notes".

To adapt this template for your environment, replace the square-bracket placeholders with concrete values. [INPUT] should be a JSON array of timestamp strings (e.g., ["2024-11-03T01:30:00 America/New_York", "2024-11-03T06:30:00 UTC"]). [TARGET_TIMEZONE] should be an IANA timezone string like "UTC" or "America/Chicago". [CONSTRAINTS] can specify DST disambiguation policy (e.g., "prefer daylight time in ambiguous cases"), maximum acceptable clock drift, or timezone abbreviation resolution rules. [EXAMPLES] should include at least one ambiguous DST case and one unparseable input to calibrate the model's behavior. After copying the template, run it against a golden test set that includes timestamps from at least three distinct timezones, one DST transition edge case, and one deliberately malformed input. Validate that every output object contains all required fields and that normalized_utc values are within expected tolerances before integrating this prompt into a production pipeline.

Integrating this prompt into an application requires treating it as a deterministic repair step within a broader data pipeline, not a standalone chat interaction. The prompt expects a batch of timestamp strings and a target timezone, and it returns a structured JSON payload. Your application should construct the prompt by injecting the [INPUT_TIMESTAMPS] array and the [TARGET_TIMEZONE] string into the template, then send the request to the model with temperature=0 and a low top_p value to maximize output consistency. Because this is a normalization task with a strict output schema, you should always use a model that supports structured output modes (e.g., GPT-4o with response_format or Claude with tool-use-as-parser) to enforce the JSON schema at the API level rather than relying solely on the prompt's instructions.

After receiving the model's response, your application must run a post-processing validation layer before ingesting the normalized timestamps into downstream systems. First, validate the top-level JSON structure against the expected schema: check that normalized_timestamps is an array, that each element contains the required fields (original, normalized_utc, source_timezone, is_ambiguous, is_dst_transition, confidence), and that all normalized_utc values parse as valid ISO 8601 strings in UTC. Second, apply business-rule validations: verify that the number of output records matches the number of input timestamps, that confidence values are within 0.0–1.0, and that any timestamp flagged with is_ambiguous: true or confidence < 0.9 is routed to a manual review queue rather than silently accepted. For high-throughput pipelines, implement a retry loop with exponential backoff (max 3 attempts) when the model returns malformed JSON or a schema mismatch, and log every retry attempt with the raw model response for debugging.

For production observability, instrument the normalization step with structured logs that capture the input batch size, the model used, latency, the number of ambiguous results, and the number of records that failed validation. If your application processes timestamps from user-generated content or external systems, consider adding a pre-processing step that detects and rejects inputs that are clearly not timestamps (e.g., empty strings, pure numbers without date separators) before they reach the model, reducing token waste and avoiding unnecessary API calls. When deploying this prompt in regulated environments where timestamp accuracy has compliance implications—such as financial audit trails or healthcare records—always require human approval for any timestamp with confidence < 0.95 or is_ambiguous: true, and preserve the original input alongside the normalized output in an immutable audit log.