A table's row labels are timestamps that are not in ascending order — what does that quietly break?

## Why order is a precondition here at all When a table's rows are named by timestamps and those timestamps run in **non-decreasing order** — each label at least as large as the one before it — a request for "everything between these two moments" has a cheap exact answer. The tool locates the position of the first boundary and the position of the second and returns the contiguous block between them. No row outside the block has to be looked at. That shortcut is correct *only* because of the order. On labels that are not sorted, a boundary search still terminates and still returns a position; it just is not the position you wanted. The block between two such positions is a contiguous run of rows that happens to sit there, and it can include moments outside the requested range and exclude moments inside it. **Nothing about the result looks wrong**: it has rows, the rows have plausible stamps, and the count is plausible too. ## The three behaviours you can actually get | Behaviour | What you see | The trap | |---|---|---| | Verify and refuse | An error naming the ordering | None — this is the friendly case, and you cannot count on it | | Fall back to a full comparison | The right rows, more slowly | You never learn the order was wrong; it bites later somewhere that does not fall back | | Proceed on the assumption | A subset that looks fine | The answer is silently wrong, and the row count will not tell you | The honest summary is that **whether the check happens is a property of the design, not of the operation's meaning**. Treat the precondition as yours to establish. ## Where the assumption spreads Range selection is the visible case. The same assumption is underneath anything that steps along the ordering: - **A span of fixed length walking the rows** covers whichever rows are physically adjacent. If the rows are out of order, "the last seven" is seven rows that are not the seven most recent moments. - **Laying a regular grid over the data** assigns records to positions by their stamps but reports them in the order it walked them; an unsorted input can produce positions out of sequence or double-visited. - **Matching two feeds on their stamps** walks both inputs once on the assumption that both advance in time. Out of order, the pointer on one side moves past a record it should have matched, and the result is silently short. - **Reading "the last value"** means the last *row*, which is the latest *moment* only when the order holds. - **Reading each row's value from the previous position** gives the previous row, which is the previous moment only under the same condition. ## Establishing it yourself 1. **Ask the question directly.** Many tools expose a way to ask whether a set of labels is non-decreasing, computed once and remembered, which makes the check nearly free to repeat. 2. **Where they do not, compare the column with a copy of itself read one position earlier**, and require every difference to be at least zero. That is one whole-column expression, not a loop, and it can also point at the first violating position. 3. **Decide which order you actually need.** Non-decreasing allows neighbours with equal stamps; strictly increasing does not. Operations differ in which one they want, and a data set with two readings at one instant satisfies the first and fails the second. 4. **Do the check where the data enters**, once, rather than defensively before every operation. A single assertion at the boundary is worth more than five scattered ones downstream. ## Order is a precondition, not an operation Putting rows into order is its own piece of work with its own decisions, and it is not what this is about. The point here is narrower and easier to miss: several time operations behave as though the order already holds, and most of them will not tell you when it does not. Two habits cover it — establish the order at the boundary, and re-establish it after any step that appends. **Appending is the usual way a sorted table stops being sorted**: a late record added at the end carries an earlier moment than its neighbour, and from that row on, every shortcut above is resting on a condition that no longer holds. ## What this looks like in a review The question to ask of a time pipeline is not "is the data sorted" but "**where is that established, and what re-establishes it after the append**". A pipeline that answers "the source emits in order" is relying on a producer's behaviour it does not control, which is a different kind of claim from a check.