Time expressions: anchors, zones and unresolved dates

Last updated: 6 Oct 20265 min read

tutorial

“Tomorrow” is not a date until its message time and local zone are known. Preserve the phrase, anchor and uncertainty together.

Treat time as a claim with context

A support note written at 23:47 may say “tomorrow,” while a reply posted minutes later comes from another time zone. Store the source span, message timestamp, claimed local zone and speaker before normalizing anything. Prefer an explicitly supplied zone over an account default, and mark the source of that choice. Never infer a zone merely from a language. Span identity keeps a normalized date tied to its original phrase.

Separate point, interval and duration

“At 08:30” is a time of day, “for 47 minutes” is a duration, and “through Friday” describes an interval endpoint. These must not share one date field. An unresolved weekday may refer to the next occurrence or a past one, depending on tense and reporting policy. Store a resolution state when the anchor is missing, rather than inventing midnight. Daylight-saving transitions can make a local wall time ambiguous or nonexistent; preserve the local expression and require an explicit offset decision.

Resolve with a policy, not a guess

For relative phrases, apply a documented rule to the message timestamp in the stated zone. Record the rule version and the normalized result. For historical reports, distinguish event time from report time: “the gateway failed yesterday” was reported today. If the source was edited, recompute the result from the new source revision. Timeline relations can then compare events without discarding their evidence.

Audit temporal errors by impact

Measure exact date agreement, zone errors, unresolved rate and downstream event-order reversals. Include midnight, month-end, daylight-saving changes and cross-zone handoffs in the audit. A system can extract the word “tomorrow” perfectly yet resolve it to the wrong calendar day. The incident timeline project tests that end-to-end behavior.

Implementation

from datetime import datetime, timedelta
from zoneinfo import ZoneInfo

def resolve_tomorrow(message_timestamp, zone_name):
    if message_timestamp.tzinfo is None:
        raise ValueError("message timestamp needs an offset")
    local_date = message_timestamp.astimezone(ZoneInfo(zone_name)).date()
    return local_date + timedelta(days=1)

reported_at = datetime.fromisoformat("2026-10-06T18:17:00+00:00")
assert resolve_tomorrow(reported_at, "Asia/Kolkata").isoformat() == "2026-10-07"

Performance and operating cost

Zone conversion and date arithmetic are O(1) for each resolved phrase; extraction over n characters is at least O(n). Zone database updates can change historical interpretation, so store the resolved value and transform version. Human review cost concentrates on missing zones and ambiguous local times; track that queue separately from ordinary extraction latency.

Common Mistakes

Resolving relative dates against processing time instead of message time.
Treating duration as an event timestamp.
Dropping the source phrase after computing a date.
Inferring a time zone from the script or language of a message.