March birthdays by day: notable people organized by date

Put a day's worth of entries in a column and the next question is what order they go in. It sounds like a formatting detail. It is the step where a list quietly decides that some names are normal and the rest are exceptions.

What to take away

• Sorting is a rule about strings, and a name is not a string in any single agreed sense.
• Every ordering choice encodes an assumption about how names are built, and most of those assumptions fail somewhere.
• A day list that sorts by a stored sort key, rather than by the displayed name, can be reordered later without touching what the reader sees.

What sorting a day actually requires

An index page for a single day holds a handful of entries. To print them in order the software has to compare two names and decide which comes first. That comparison is collation, and it is not the same as comparing the numeric values of characters. The obvious approach, comparing byte by byte, puts every capital letter before every lowercase one and scatters accented characters far from the letters they belong with.

Real collation is language dependent. The same two strings sort differently under different conventions, because the conventions are about a written language and not about storage. The Unicode collation algorithm exists to give a defined default and a way to tailor it, which is the honest shape of the problem: there is a sensible answer, and it depends on who is reading.

Where the assumption breaks

The common design stores a given name and a family name, sorts on the second, and displays the first. That works for a large share of the world and fails for the rest.

Name shape	What the two-field model does	What it should do
A single name with no family name	Leaves a field empty and sorts on nothing	Store one name and a sort key equal to it
A mononym used professionally beside a longer legal name	Picks one arbitrarily	Store both, mark which is for display
A patronymic that changes each generation	Treats it as an inherited surname	Record that the second element is not a family name
A name written family-name-first in its own script	Reverses it on import	Keep the original order and a separate romanized form
A compound family name joined by a particle	Splits at the space and sorts on the particle	Store the sort key the person or their community uses

None of these are rare edge cases. Each of them is ordinary somewhere, and the failure is silent: the entry appears in the wrong place and nobody notices, because nobody knows where it should have been.

The fix is a second field

Store a sort key alongside the displayed name and let a human set it when the automatic guess is wrong. The reader sees the name as written. The list sorts on the key. When the convention changes, or when the person tells you the guess was wrong, you edit one field and the display is untouched.

That is not a clever trick. It is what library catalogs have done for a long time, and the reason they can shelve a work by an author whose name does not fit the local pattern. The same separation is what lets the January by-day pages hold entries from records with very different naming conventions without forcing them all into one shape.

What this means for a day in this month

• Two entries that look adjacent in a printed list may have arrived by completely different routes. Order is not evidence of similarity.
• An entry whose sort key is missing tends to sink to the top or the bottom of a list, depending on the language runtime. That position means nothing.
• Alphabetical order is not neutral. It privileges the naming convention the sort was written for.
• If a day's list looks suspiciously well ordered by nationality, the sort key is probably doing something you did not intend. The March index treats the month as a slice rather than a category for the same reason.
• A reordered list is not a corrected list. Fixing the order does nothing about whether the entries belong there, which is the question the February by-day pages work through.

Common questions

Why not just sort by the name as displayed?

Because the displayed name is chosen for the reader and the sort key is chosen for the machine, and they answer different questions. Forcing one field to do both means one of the two jobs gets done badly.

Is there a correct order for a day's entries?

There is a defensible one, once you say which convention you are following and why. There is no order that is correct independent of that choice, which is why a page that states its ordering rule is more useful than one that looks tidy.

Does the order say anything about the people listed?

No. It says something about the software. A reader who infers rank, importance or closeness from position on a day page is reading a formatting decision as a claim, and the page should not invite that.

What should happen when someone says their name sorts wrongly?

Edit the sort key and leave the display alone. That is the whole point of keeping them apart, and it is the one correction a list of this kind can make immediately and without argument. The route for asking is set out on the January index.