Timestamp Precision Normalization Prompt Template

This prompt is a post-generation repair tool for observability platform engineers and data lake operators who must align timestamps with mixed precision levels—seconds, milliseconds, microseconds, and nanoseconds—into a single, consistent target precision. It is not a schema design tool or a general-purpose date parser. Use it when downstream systems like time-series databases (e.g., InfluxDB, TimescaleDB), log aggregators (e.g., Splunk, Loki), or analytics engines (e.g., ClickHouse, Trino) require uniform timestamp precision for correct indexing, partitioning, and comparison. The prompt applies a specified rounding rule and explicitly flags when precision has been altered, giving you an auditable record of the transformation.

Do not use this prompt for initial timestamp parsing from unstructured text, timezone correction, or date format detection. Those tasks require separate, upstream normalization steps before precision alignment. This prompt assumes you already have a valid, parsed timestamp and need to adjust its sub-second precision. It is also not a substitute for fixing the source of precision inconsistency—if your ingestion pipeline is producing mixed nanosecond and second timestamps from the same event source, address that at the schema or serializer level first. Use this prompt when you are repairing already-ingested data or handling outputs from multiple upstream systems that you do not control.

Before deploying this prompt into a production pipeline, build a validation harness that checks the output against your target precision specification. Verify that the rounding rule (floor, ceil, or round-half-up) matches your organization's standard, and test edge cases like timestamps exactly at rounding boundaries (e.g., 500 microseconds when rounding to milliseconds). If your use case involves financial compliance, audit trails, or regulatory reporting, require human review of any batch where the precision change flag is set. The next section provides the copy-ready prompt template you can adapt and test against your own timestamp corpus.

This template is the core instruction set for a Timestamp Precision Normalization task. It is designed to be copied directly into your AI workflow, with placeholders that you replace with your specific inputs, constraints, and output requirements. The prompt instructs the model to analyze an input timestamp, detect its current precision, and transform it to a target precision using a specified rounding rule. It also requires the model to output a structured flag indicating whether the precision was changed, making the operation auditable in downstream pipelines.

markdownCopy
Normalize the precision of the following input timestamp to the target precision.

[INPUT_TIMESTAMP]

TARGET PRECISION: [TARGET_PRECISION]
ROUNDING RULE: [ROUNDING_RULE]

INSTRUCTIONS:
1. Analyze the input timestamp to determine its current precision (e.g., seconds, milliseconds, microseconds, nanoseconds).
2. Convert the timestamp to the target precision by applying the specified rounding rule.
3. If the input timestamp is missing a timezone offset, assume [DEFAULT_TIMEZONE].
4. Output the result as a single, valid JSON object conforming to the schema below.

OUTPUT_SCHEMA:
{
  "normalized_timestamp": "string (ISO 8601 format with the target precision)",
  "original_precision": "string (detected precision of the input)",
  "target_precision": "string (the requested target precision)",
  "precision_changed": boolean,
  "rounding_applied": "string (description of the rounding operation, or 'none')"
}

CONSTRAINTS:
- The `normalized_timestamp` MUST be a valid ISO 8601 string.
- Do not change the point in time; only change its precision.
- If the input precision is already equal to the target precision, set `precision_changed` to false and `rounding_applied` to 'none'.
- If the input is invalid or unparseable, set `normalized_timestamp` to null and explain the error in a new `error` field.

To adapt this prompt, replace the placeholders with your specific operational parameters. [INPUT_TIMESTAMP] should be the raw timestamp string from your source system. [TARGET_PRECISION] should be one of 'seconds', 'milliseconds', 'microseconds', or 'nanoseconds'. [ROUNDING_RULE] must be a clear directive like 'round half up', 'round down' (truncate), or 'round half to even'. The [DEFAULT_TIMEZONE] placeholder is critical for timestamps that lack an explicit offset; setting this to 'UTC' is a common and safe default. The OUTPUT_SCHEMA is designed to be parsed by a downstream application, so ensure your code strictly validates the normalized_timestamp field before use. For high-stakes pipelines, you should add a [FEW_SHOT_EXAMPLES] section to the prompt to disambiguate edge cases like rounding 999999 microseconds up to the next second.

The Timestamp Precision Normalization prompt is designed to be called as a post-extraction repair step within a data pipeline, not as a user-facing chatbot. The typical integration point is immediately after a model or parser emits a timestamp that fails a downstream schema check due to precision mismatch. The application should catch the validation error, extract the offending timestamp and the target precision, and construct the prompt call with these as [INPUT_TIMESTAMP] and [TARGET_PRECISION]. The [ROUNDING_RULE] should be sourced from a pipeline configuration constant (e.g., 'round-half-up' or 'truncate') rather than left to the model to infer, ensuring deterministic behavior across batches.

Wrap the LLM call in a thin service function that enforces a strict contract. The function must accept a single timestamp string, a target precision enum ('seconds', 'milliseconds', 'microseconds', 'nanoseconds'), and a rounding rule. It should construct the prompt, call the model with temperature=0 and a low top_p to maximize deterministic output, and parse the response against a JSON schema that requires normalized_timestamp, applied_precision, precision_changed (boolean), and applied_rule fields. If the response fails schema validation, retry once with the validation error appended to the prompt as additional [CONSTRAINTS]. If the retry also fails, log the raw response, increment a precision_normalization_failure metric, and route the record to a dead-letter queue for manual inspection. Do not silently pass through the original timestamp.

For observability, log the precision_changed flag and the applied_rule as structured metadata on the pipeline record. This allows data lake operators to later query how many records were altered and by which rule. In high-throughput pipelines, consider batching multiple timestamps into a single prompt call with a JSON array input and output to reduce API overhead, but keep batch sizes small (under 20 timestamps) to avoid partial failures. If the pipeline processes timestamps that are already at the target precision, short-circuit the LLM call entirely by checking the input precision with a regex or datetime library before invoking the model—this saves cost and latency for the common no-op case.