---
title: "What is event ordering?"
description: "Event ordering places stored events in the sequence they happened, by event time rather than arrival. Why records arrive out of order and what fixes it."
canonical: https://past.dev/glossary/event-ordering
last-updated: 2026-09-02
---
# What is event ordering?

Source: https://past.dev/glossary/event-ordering

Event ordering is placing stored events in the sequence they actually happened, using event time rather than arrival order. Records reach a memory system out of sequence: syncs batch, imports backfill, timezones skew local clock readings, and sources deliver at different speeds. Ordering by each record's own timestamp reconstructs the world's sequence, so an agent can say which decision came first and which value is latest.

## Why arrival order differs from event order

- **Backfills**: a 2024 archive imported in 2026 arrives after everything it precedes.
- **Sync cadence**: email may sync each minute while a ticketing system syncs hourly, so a later event can arrive earlier.
- **Timezones**: a 15:47 Tokyo message and an 08:12 London message on the same day cannot be ordered by local clock readings alone.
- **Clock differences**: sources stamp in local time; ordering requires normalizing every timestamp to one scale such as UTC.

## How event ordering works

1. Read each record's own timestamp with its timezone offset ([event time](/glossary/event-time)).
2. Normalize all timestamps to a single scale, usually UTC.
3. Sort and compare on the normalized value; keep arrival ([ingestion time](/glossary/ingestion-time)) as a separate field.
4. When two events share a timestamp or lack one, use explicit tie-breakers (thread position, sequence numbers) and record the uncertainty.

Ordering errors produce wrong answers delivered with confidence. An agent that sorts by arrival treats the last import as the latest news, reports superseded values as current, and reconstructs conversations with replies placed before the messages they answer. Memory benchmark suites test ordering directly, with questions whose correct answer is a sequence; the [benchmark methodology](/benchmarks/methodology) describes the construction. past.dev dates and orders facts by the event time supplied with each record at ingest rather than by arrival.

## Event ordering in practice

Two messages about the Meridian offer reach a memory system during a Monday sync. The email synced within minutes; the chat channel syncs hourly and delivered its message forty minutes after the email.

| Record | Sent (local) | Sent (UTC) | Arrived (UTC) |
| --- | --- | --- | --- |
| Chat from Tokyo: "revise the offer before it goes out" | Mon 15:47 JST | 06:47 | 10:04 |
| Email from London: "final offer sent to Meridian" | Mon 08:12 BST | 07:12 | 09:22 |

By arrival, the revision request appears to follow the send and reads as a new instruction. By event time, the request preceded the send by twenty-five minutes, which changes what the agent should do next. Only the event-time reading matches what happened.

## Related concepts

- **[Event time](/glossary/event-time)**: the timestamp ordering sorts on.
- **[Ingestion time](/glossary/ingestion-time)**: arrival order, kept separately for audit.
- **[Temporal reasoning](/glossary/temporal-reasoning)**: the broader ability ordering belongs to.
- **[Fact supersession](/glossary/fact-supersession)**: replacement decisions that depend on correct order.
- **[Bitemporal memory](/glossary/bitemporal-memory)**: storing both orderings side by side.

## Frequently asked questions

### Why do AI agents get event order wrong?

Records arrive in an order set by sync schedules, imports, and timezones rather than by when things happened. An agent that sorts by arrival treats its integration timing as the order of events.

### How do you order events across timezones?

Keep each record's original timestamp with its timezone offset, convert all of them to one scale such as UTC, and compare on that. A 15:47 Tokyo message is 06:47 UTC and can precede a same-day 08:12 London message.

### What if two events have the same timestamp?

Use explicit tie-breakers such as thread position or sequence numbers, and record that the order is uncertain when none exist. Guessing an order silently is worse than reporting a tie.

## Related

- [Temporal reasoning](https://past.dev/glossary/temporal-reasoning)
- [Event time](https://past.dev/glossary/event-time)
- [Event time vs ingestion time](https://past.dev/guides/event-time-vs-ingestion-time)
- [Memory API quickstart](https://past.dev/docs/memory-api/quickstart)
- [Benchmark methodology](https://past.dev/benchmarks/methodology)