What breaks in a generated dataset whose records all carry the same creation timestamp?

## Three jobs a time value does in generated data A time value in a manufactured dataset is doing three different jobs at once, and a set where every value is identical fails all three: - **Filtering.** Range queries — the last day, the last month, anything older than a retention age — decide which rows are in scope. - **Ordering.** Sorting and cursor paging use the value to decide what comes first and what comes next. - **Causality.** The relative order of two values encodes that one thing happened after another, which is a rule the product enforces and reports on. Collapse the history into one instant and every range filter matches all rows or none of them, every sort becomes a mass of ties, and every causal comparison is trivially equal. ## The orderings a generated history has to satisfy 1. **Within an entity**: creation no later than any update, and no later than closure or removal. 2. **Across related entities**: a child is never created before the parent it references. Products routinely enforce this, and data that violates it produces rejections that look like product bugs. 3. **Along an event sequence**: each transition follows the one it depends on — placed, then paid, then shipped, then delivered — with no two occupying the same instant if the product orders them by time. 4. **Plausible intervals**: a step a person performs takes minutes, not microseconds; a delivery is days after an order. A history that is causally correct but instantaneous still fails every assertion about elapsed time, and every feature that reports one. 5. **Global spread**: rows inside every window a feature queries — something inside today, something inside the last month, something older than the oldest ageing rule. ## What a single instant costs, item by item | What the product does with time | With a spread history | With one instant | |---|---|---| | Range filter | Some rows in, some out; the boundary is exercised | All rows or none; the boundary logic never runs | | Ageing, expiry, retention | Old rows exist, so the path fires | Nothing is old, so the path never fires | | Sort by time | A defined order | Ties, and the order is whatever the store returns | | Cursor paging on a time value | Pages advance | Pages repeat or skip, because ties break the cursor | | Grouping into periods | Several buckets, so a bucketing mistake is visible | One bucket, so a bucketing mistake is invisible | | Ordering invariants | A violation can be detected | Everything compares equal, so nothing is ever violated | The last row is the quietest. If creation and update always hold the same value, a bug that writes them the wrong way round is undetectable, because the assertion that creation is not after update passes on equality. ## Ties are a flakiness source, not a cosmetic flaw Bulk generation stamps rows from one call, so hundreds of rows land on the same value. A sort on equal keys has no defined winner: the order comes from whatever the store finds first, which depends on physical layout, on the plan chosen, and on how the rows were written. A test that asserts which row comes first then passes on the machine it was written on and fails elsewhere, with a difference that looks like corruption rather than an undefined order. There are two repairs and you want both. Make the value distinct on any field used for ordering, and give every ordering that matters a deterministic secondary key, so the result is defined even when two values are genuinely equal. ## Anchor the history to a reference instant Generate every value as an **offset from one reference instant** captured when the set is built, rather than as a fixed calendar value. The set then has the same internal shape whenever it is built, and the offsets are what the assertions talk about. That raises a decision worth making deliberately: is the set regenerated per build, or loaded once and reused? A set of fixed values loaded once slides out of every recent-window query as real time passes. Features that looked fine in week one return nothing in month six, and the failure has no change to blame. Either regenerate against a current reference instant on every build, or shift the whole history by a constant offset when it is loaded, so its relationship to today is preserved. ## Do not over-fit A generated history does not have to be realistic in every respect. It has to be **ordered** wherever the product depends on order, **spread** across every window the product queries, **distinct** on whatever it sorts by, and **plausible** in its intervals wherever elapsed time is reported. Those four properties are cheap to assert at generation time, and asserting them is what stops a history that looks fine in a viewer from quietly disabling half the product's behaviour.