← Back to blog
·5 min read·SettleRisk Team

Temporal Ambiguity: Why Timezone Bugs Account for One in Five Disputes

Deep Dive

Executive Summary

Roughly one in five disputed prediction-market resolutions trace back to a timezone or date-window ambiguity. The fix is mechanically obvious — name a timezone and a precise instant. The reason it keeps happening is that contract authors are usually writing for human readers who infer the timezone from context, while resolution mechanisms need the exact ISO-8601 string.

This post breaks down the four sub-patterns of temporal ambiguity SettleRisk detects, walks through a Polymarket dispute caused by exactly this, and shows the SDK code to flag temporal risk before quoting.

Core Concept

The TEMPORAL_AMBIGUITY driver covers four detected sub-patterns:

| Sub-pattern | Example | Detection difficulty | |-------------|---------|---------------------| | Missing timezone | "by end of day Friday" | Easy | | Date-only with intraday event | "on June 30" for an intraday event | Easy | | Vague window boundary | "by mid-summer" | Medium | | Open-ended window | "by the end of the year" without year | Medium |

Each contributes sub-points to the TEMPORAL_AMBIGUITY driver, capped at the driver's max_points. A market with two of these sub-patterns can reach the cap on this driver alone.

Worked Example

Real dispute from March 2025: a Polymarket on "Will [CEO X] resign by end of day Friday?" resolved at 11:30 PM UTC on Friday, which was 6:30 PM EST. Traders on the East Coast considered the day over; traders in Asia considered Friday already gone. The market spent 14 days in dispute before being resolved on the company's HQ timezone (PST), where the event occurred at 3:30 PM Friday afternoon.

SettleRisk's extraction:

from settlerisk import SettleRiskClient

client = SettleRiskClient(api_key="sk-...")
extraction = client.evaluate_rules(
    platform="polymarket",
    rules_text="This market resolves YES if CEO X publicly announces "
               "resignation by end of day Friday, March 14, 2025.",
)

for d in extraction.drivers:
    if d.driver_type == "TEMPORAL_AMBIGUITY":
        for p in d.sub_patterns:
            print(f"  {p.type}: '{p.text_span}' ({p.sub_points} pts, conf={p.confidence:.2f})")

  missing_timezone: 'end of day Friday' (5 pts, conf=0.94)

A single sub-pattern, but enough to push the driver to MEDIUM strength and add 11 points to the score. Combined with AMBIGUOUS_WORDING from the word "publicly" (which is also vague), the market scored 58 — HIGH tier.

TypeScript:

import { SettleRiskClient } from "settlerisk";

const client = new SettleRiskClient({ apiKey: "sk-..." });
const extraction = await client.evaluateRules({
  platform: "polymarket",
  rulesText:
    "This market resolves YES if CEO X publicly announces resignation by end " +
    "of day Friday, March 14, 2025.",
});

for (const d of extraction.drivers) {
  if (d.driverType === "TEMPORAL_AMBIGUITY") {
    for (const p of d.subPatterns ?? []) {
      console.log(`  ${p.type}: '${p.textSpan}' (${p.subPoints} pts, conf=${p.confidence.toFixed(2)})`);
    }
  }
}

Implementation Notes

Missing timezone is the dominant sub-pattern. ~80% of temporal-ambiguity disputes trace to a missing or ambiguous timezone. The fix is trivial in principle: name the timezone (UTC, EST, etc.) and specify the instant.

Date-only resolutions are dangerous for intraday events. "Will X happen on June 30?" sounds precise but doesn't say whether 11:59 PM UTC or 11:59 PM PT counts. Treat all date-only rules around intraday events as MEDIUM-tier minimum.

Vague window boundaries (mid-summer, end-of-Q3) are reviewer hell. These require the resolver to interpret. SettleRisk treats them as MEDIUM strength regardless of context because the interpretation cost is non-zero.

Open-ended windows ("by the end of the year") are the lowest-frequency but highest-loss sub-pattern. They tend to appear on long-dated political markets where the dispute economics are non-trivial.

| Pattern | Fix | |---------|-----| | Missing timezone | Append " UTC" or specify market HQ timezone | | Date-only intraday | Add "at 23:59:59 UTC" or similar | | Vague window | Replace with explicit date range | | Open-ended | Add year explicitly |

For your own pre-filter, a simple regex catches the majority of cases:

import re

TZ_PATTERN = re.compile(
    r"\b(UTC|EST|PST|GMT|EDT|PDT|CET|JST)\b", re.IGNORECASE
)
TEMPORAL_TRIGGER = re.compile(
    r"\b(end of day|by friday|by monday|by tuesday|by wednesday|"
    r"by thursday|by saturday|by sunday|mid-summer|end of year|"
    r"end of quarter|q[1-4])\b",
    re.IGNORECASE,
)

def temporal_risk_flag(rules: str) -> bool:
    if TEMPORAL_TRIGGER.search(rules) and not TZ_PATTERN.search(rules):
        return True
    return False

That catches roughly 70% of temporal-ambiguity cases.

Failure Modes

1. Assuming UTC by default. Different venues default to different timezones. Polymarket historically defaults to UTC, Kalshi to ET. Do not assume.

2. Missing the conversion between event timezone and resolution timezone. A Fed announcement happens in DC time; a market resolves in venue time. Both need to be explicit.

3. Ignoring daylight savings. Markets that span a DST transition can have ambiguous "end of day" windows during the transition week. Annoying but real.

4. Confusing publication time with effective time. A document dated "March 14" may have been released at 11 PM on March 13 in some jurisdiction. The dating convention matters.

5. Skipping the audit trail. When a temporal-ambiguity dispute is resolved, the resolver picked a specific interpretation. Persist that interpretation in your audit log so similar markets get sized accordingly.

Checklist

  • [ ] Pre-filter rules for TEMPORAL_TRIGGER keywords lacking a TZ_PATTERN
  • [ ] Treat date-only rules for intraday events as MEDIUM tier minimum
  • [ ] Document the venue's default timezone in your scoring config
  • [ ] Watch DST transition weeks for above-average risk
  • [ ] Subscribe to rules.changed to catch retroactive timezone clarifications
  • [ ] Persist resolved interpretations as a lookup table

Sources + Further Reading

  • SettleRisk methodology — full TEMPORAL_AMBIGUITY sub-pattern logic
  • Ambiguous wording post — linguistic sibling
  • ISO 8601 standard — canonical timestamp format
  • Polymarket UMA Dispute Tracker — empirical timezone-dispute history
  • Standardizing Resolution Time Notation in Event Markets (working paper, 2024)

Test a rule for temporal risk: /demo accepts pasted rules text, no key required.

Get weekly risk analysis in your inbox

Market risk scores, emerging dispute patterns, and settlement delay trends — delivered every Monday.