Timestamp Truncation Repair Prompt

This prompt is designed for log aggregation pipeline operators and SRE teams who need to repair timestamps that were silently truncated during serialization, ingestion, or transport. The primary job-to-be-done is restoring missing precision—such as milliseconds, microseconds, or seconds that were set to zero or dropped entirely—so that downstream systems can correctly order, query, and analyze event streams. The ideal user is an engineer responsible for a log pipeline (e.g., Fluentd, Logstash, Vector) or an observability platform (e.g., Datadog, Splunk, Grafana Loki) who has identified a systematic truncation pattern in incoming records and needs to apply a consistent repair rule before the data lands in storage.

Use this prompt when you have a batch of timestamps that share a known truncation signature—for example, all timestamps ending in .000 when sub-second precision is expected, or all seconds fields set to 00 in a format that should include seconds. The prompt requires you to provide the raw timestamp string, the expected format specification (e.g., ISO 8601, syslog RFC 5424, Apache Common Log Format), and the suspected truncation pattern. It is not suitable for general timestamp normalization (use the ISO 8601 Normalization Prompt instead), for disambiguating locale-specific date formats, or for repairing timestamps with completely missing components. Do not use this prompt when the truncation pattern is unknown or varies per record—in that case, route to the Timestamp Anomaly Detection Prompt first to classify the damage before attempting repair.

Before invoking this prompt in a production pipeline, ensure you have validated the truncation pattern against a representative sample of records. The prompt will return a repaired timestamp and a detected precision restoration level, but it cannot guarantee correctness if the truncation signature is misidentified. Always run eval checks against a golden dataset of known pre-truncation timestamps to measure repair accuracy. For high-volume pipelines, consider batching records that share the same truncation pattern and applying the repair at the ingestion layer rather than calling the model per-record. If the repair involves timestamps used for compliance, billing, or security auditing, require human review of the repair logic before enabling automated correction.

This prompt template is designed to be copied directly into your application or prompt management system. It instructs the model to analyze a corrupted timestamp, detect the truncation pattern (e.g., missing milliseconds, seconds zeroed out), and produce a repaired timestamp with metadata about the restoration. All square-bracket placeholders must be replaced with real values before execution. The template assumes you have already validated that the input is a malformed timestamp and not a completely unrelated string.

textCopy
You are a timestamp repair specialist. Your task is to analyze a timestamp that was truncated during serialization, detect the truncation pattern, and produce a repaired timestamp with the highest precision that can be reasonably restored.

INPUT:
[RAW_TIMESTAMP]

CONTEXT:
- Expected format: [EXPECTED_FORMAT, e.g., ISO 8601, RFC 3339, Unix epoch]
- Source system: [SOURCE_SYSTEM, e.g., syslog, application log, database export]
- Known serialization issues: [KNOWN_ISSUES, e.g., 'milliseconds stripped by log shipper', 'seconds always zero in batch exports']
- Timezone if known: [TIMEZONE, e.g., UTC, America/New_York]

OUTPUT_SCHEMA:
{
  "original_timestamp": "string (the raw input)",
  "repaired_timestamp": "string (the repaired timestamp in the expected format)",
  "detected_truncation_pattern": "string (e.g., 'missing_milliseconds', 'seconds_zeroed', 'missing_timezone', 'no_truncation_detected')",
  "precision_restored_to": "string (e.g., 'milliseconds', 'seconds', 'microseconds')",
  "repair_confidence": "string (high | medium | low)",
  "repair_method": "string (brief explanation of how the repair was performed)",
  "warnings": ["string (any caveats about the repair)"]
}

CONSTRAINTS:
- Do not invent precision that cannot be inferred from the input or context.
- If the timestamp appears intact, set detected_truncation_pattern to 'no_truncation_detected' and return the original value as repaired_timestamp.
- If the truncation pattern is ambiguous, set repair_confidence to 'low' and include a warning.
- For syslog timestamps missing year, infer the year from the current date context if provided.
- Never shift the actual time value unless correcting an offset error documented in the context.

EXAMPLES:

Input: "2025-03-15T14:30:00Z"
Context: Expected format ISO 8601 with milliseconds. Source: application log. Known issue: milliseconds stripped by log shipper.
Output:
{
  "original_timestamp": "2025-03-15T14:30:00Z",
  "repaired_timestamp": "2025-03-15T14:30:00.000Z",
  "detected_truncation_pattern": "missing_milliseconds",
  "precision_restored_to": "milliseconds",
  "repair_confidence": "medium",
  "repair_method": "Appended .000 milliseconds as default restoration since original sub-second data is unrecoverable.",
  "warnings": ["Original millisecond value is lost. Restored to zero as placeholder."]
}

Input: "Mar 15 14:30:00"
Context: Expected format ISO 8601. Source: syslog. Known issue: year missing, seconds always zero.
Output:
{
  "original_timestamp": "Mar 15 14:30:00",
  "repaired_timestamp": "2025-03-15T14:30:00Z",
  "detected_truncation_pattern": "missing_year",
  "precision_restored_to": "seconds",
  "repair_confidence": "medium",
  "repair_method": "Inferred year from current date context. Seconds field was already zero and matches known issue pattern.",
  "warnings": ["Year inferred from context, not original data. Verify if log spans multiple years."]
}

Now repair the INPUT timestamp and return only the JSON object matching OUTPUT_SCHEMA.

To adapt this template, replace the placeholders with your actual values. The KNOWN_ISSUES field is critical for guiding the model toward the correct repair strategy—be specific about what your serialization pipeline does to timestamps. If you have multiple truncation patterns in your data, consider adding a truncation_pattern input field and branching to different prompt variants. For production use, always validate the output JSON against the schema before accepting the repair, and log the repair_confidence value to track repair quality over time.

This prompt is designed to be called as a post-ingestion repair step within a log aggregation pipeline, not as a standalone interactive tool. The typical integration point is immediately after a log record is parsed and its timestamp field fails a completeness or precision check. The application should extract the malformed timestamp string, the expected format (e.g., ISO 8601), and any available context like the log source or ingestion time, then pass them as the [INPUT_TIMESTAMP], [TARGET_FORMAT], and [CONTEXT] variables to the prompt. The model's response must be parsed as a structured JSON object containing the repaired timestamp, the detected truncation pattern, and a precision restoration level.

A robust harness requires a strict validation layer before the repaired timestamp is written back to the data store. After receiving the model's JSON response, validate that the repaired_timestamp field is a valid ISO 8601 string that can be parsed by your application's date library. Check that the precision_restoration_level matches one of the expected enum values (e.g., milliseconds, seconds, microseconds). If validation fails, implement a single retry with a more explicit error message fed back into the [CONSTRAINTS] variable, such as 'Previous repair attempt produced an unparseable timestamp. Ensure the output strictly matches ISO 8601 with the correct precision.' If the retry also fails, log the original malformed timestamp, the failed repair attempts, and the raw model response to a dead-letter queue for manual inspection. Do not silently drop records.

For model choice, a fast, cost-effective model like GPT-4o-mini or Claude Haiku is usually sufficient, as the task is a narrow, pattern-matching repair. However, if your logs contain highly irregular truncation signatures from legacy or proprietary systems, a more capable model may be required for the initial classification of the truncation pattern. Implement a circuit breaker: if the detected_truncation_pattern field returns unknown above a threshold rate (e.g., 5% of requests), the harness should alert an operator and optionally escalate to a more powerful model or a human review queue. All prompt requests and responses should be logged with trace IDs that correlate back to the original log record, enabling offline evaluation and prompt iteration. Never use a repaired timestamp to overwrite the original raw timestamp field; always store it in a separate, clearly labeled column like repaired_timestamp to maintain an audit trail and enable rollback.