What does making the timestamp the row labels of a table buy, and what does it cost?

## What promoting the stamp actually does A table of readings normally arrives with the moment of each reading sitting in a column, next to the value, the source and whatever else the record carries. **Promoting the stamp** means telling the tool to treat that column as what the rows are *named and ordered by* rather than as one more field: the row-label structure — the index, in the usual term of art, meaning the structure that names and orders the rows — is now made of timestamps. Not every design in this family has such a concept. Some tools keep a table as a plain set of typed columns from beginning to end, with no row-label structure at all, and there the same time operations are told which column carries the ordering by **naming it as an argument**. So the general statement is not "you must promote the stamp" but *the tool has to be able to find the ordering, and promotion is one of the two ways that happens*. ## What promotion buys - **A range asked for by naming two moments.** Instead of writing a condition over a column — greater than this, less than that — you name the two endpoint moments and get the block between them. That is a shorter thing to say and a different thing to execute, because sorted labels can be located by boundary search rather than by testing every row. - **A shared ordering to line up on.** When two objects carry the same kind of row labels, operations that combine them have something to line up on other than physical position. What each tool does with a mismatch varies, but the ordering is at least available to it. - **Discoverability.** Operations that re-space the data onto a regular grid, or walk a span along it, need to know which column is time. Where the labels carry it, they do not have to be told on every call. - **Traversal in a meaningful order.** Printing, taking the first or the last few, and stepping through the rows all follow time rather than insertion. ## What promotion costs - **The slot is singular.** A record usually carries more than one moment — when the thing happened, when you received it, when it became true. Exactly one of them can be the labels. The others must remain ordinary columns; dropping them is the mistake that cannot be undone later. - **The promoted column may stop behaving like an ordinary column.** In designs with a row-label structure, an operation "over all columns" may skip it, a writer may or may not emit it, and getting it back as a field is a deliberate step. This is a real difference in behaviour, not a formality. - **Two preconditions ride along, and they are quiet.** The labels are assumed to be in non-decreasing order, and they are assumed to identify a row. Promotion itself generally establishes neither: it does not put the rows in order, and in several designs it does not reject repeats. ## Where designs differ | Question | Designs with a row-label structure | Designs without one | |---|---|---| | How is the ordering found? | From the labels themselves | From a column named as an argument | | Can a range be named by two moments? | Yes, addressed through the labels | Usually as a condition over the named column | | Is the stamp still an ordinary column? | Often not, or only with an explicit step | Yes, throughout | | What lines two objects up? | The shared labels, where the design supports it | Position, or an explicit match you write | A candidate who answers only for the design they know is answering half the question. Say what promotion buys *where the concept exists*, and say how the same need is met where it does not. ## When the label is a whole span The labels do not have to be instants. A label can be a **named period** — a value that stands for a whole span, such as 2026-03, rather than a single moment. That is honest for data that really is monthly, and it reads better than pinning a month to an arbitrary instant. The cost appears the moment such a label meets a single timestamp: a span has a start and an end, so the comparison has to resolve it to one of them, and the result depends on which. Convert deliberately rather than letting the comparison choose for you. ## Doing it deliberately 1. **Decide which of the record's times answers your questions**, and promote that one. 2. **Keep the others as ordinary columns.** They are how you later measure lateness or reconstruct what was known when. 3. **Establish the two preconditions explicitly** — confirm the labels are non-decreasing, and find out whether they repeat — because promotion will not tell you. 4. **Write the operation so it still reads sensibly in a design with no row labels**, by keeping the name of the time column visible in your own code rather than leaning on it being implicit.