Rules
Part of May birthdays: how to search and verify records
May birthdays by day: notable people organized by date
May birthdays by day: the number stored under every date, what a spreadsheet does to a day column, and the checks that survive an import pipeline intact.
A date rarely reaches a published page by hand. It travels through a spreadsheet, a CSV file, a database column and a template, and each of those has an opinion about what a date is. Most of the wrong dates on the internet were correct when someone typed them.
What to take away
- A date is stored as a number counted from an arbitrary starting point, and different systems count from different points.
- Spreadsheets guess at what you meant, convert on the guess, and keep no record of the original text.
- The only safe interchange form is an unambiguous written date, kept as text, checked after every hop.
The number under the date
Software does not store a date as the words you see. It stores an offset from a fixed instant, and that instant is the epoch. Different platforms picked different epochs and different units, so the same stored number means different days depending on who reads it. Move a column between two systems without declaring the format and the whole column shifts by a constant, which is the most dangerous kind of error because everything still looks like a date.
A constant offset does not announce itself. Nothing is malformed. Every row is plausible. The only way to catch it is to check a row whose correct value you already know, which is why an import should always carry a few known-good entries whose job is to fail loudly.
What a spreadsheet does to a day column
Paste a column of days into a spreadsheet and it will try to interpret each cell. What happens next depends on the software, the locale setting and the exact characters in the cell.
| What you typed | What can come back | Why |
|---|---|---|
| A day and month with no year | A date in the current year | The parser fills the missing field rather than refusing |
| A two-digit year | A year in the wrong century | A windowing rule decides which century, and the rule is not universal |
| A day above twelve with a slash | Sometimes text, sometimes a date | The value is unambiguous, so the parser may or may not commit |
| A leading zero on a day number | The zero stripped | The cell was read as a number, not a label |
| A name that looks like a date fragment | A date | Autoconversion does not check whether the column is names |
The last row is not hypothetical. Fields that were never meant to be dates get converted whenever they resemble one, and the original text is gone. Formatting the column as text before pasting prevents it. Formatting it afterward does not, because the conversion already happened.
The two-digit year is still with us
The year 2000 problem was fixed in the systems people were worried about. It was not fixed in every export, every legacy file and every hand-kept sheet, and a two-digit year is still a common way to write a date. A stored two-digit year is not a compressed date. It is a date with a missing field and a guess in its place, and the guess is made by whichever program reads it next.
For a birthday index this matters more than for most data, because the year is the field that decides which century a record belongs to, and the day and month look perfectly fine either way. An entry that has silently moved a hundred years still renders as a valid day of May.
Rules that survive the pipeline
- Keep the original string. Whatever the parsed value becomes, the text somebody actually wrote is the only thing that can settle a dispute later.
- Write dates in full, in a form with a four-digit year and an unambiguous month, and keep them as text in transit.
- Check totals after every hop. If a column of days has a different count of distinct values than it started with, something converted.
- Never accept a date the pipeline invented to fill a gap. A missing field should stay missing, in the way the January by-day pages describe for partial dates.
- Re-derive display formats from the stored value rather than storing the formatted string, so that a change of convention does not require another pass over the data.
Common questions
Is this really how wrong dates get published?
Often, yes. The interesting errors are rarely someone typing the wrong digit. They are a correct value read by a system that assumed a different convention, and they arrive in bulk rather than one at a time.
Why does the day and month survive when the year breaks?
Because the day and month are bounded and self-checking, and the year is not. A day of 32 is obviously wrong. A year that is off by a century is a perfectly ordinary year. The May index works through what a month field can and cannot be evidence of.
Should a page like this show the day at all?
It can show the day it holds, provided it also shows how confident it is. The distinction between a recorded value and a value that a parser supplied is the one the February by-day pages treat as the whole point, and it is worth stating on every entry rather than in a note nobody reads.
What is the single most useful check?
Round-tripping. Export what you imported, compare it to the source file, and look at every row that differs. It costs an hour and it catches the class of error described above, which no amount of reading the rendered page will find. The January index sets out the correction route once something does slip through.