Features
September birthdays: a practical directory for 2027
September birthdays: the days a calendar reform removed, dates the calendar never had, and how to build a check that catches an impossible entry.
There are dates that never happened. Some months lack them, some years lack them, and some countries removed a run of them on purpose. A good index checks for all three, because an impossible date is the clearest signal a record can give that something went wrong on the way to the page.
What to take away
- Some calendar dates did not exist in some places: the days dropped when a country changed calendars, and the days a month does not have.
- A date validator needs the calendar and the jurisdiction, not only the digits.
- Impossible dates are useful. Each one points at the exact step where a record was mishandled, and at the other records that passed through the same step.
The days that were removed
When a country adopted the Gregorian calendar it had to discard the days the Julian calendar had accumulated. How many depended on when the switch was made: ten in 1582, eleven by the eighteenth century, thirteen by the twentieth. In Great Britain and its colonies the change was made under the Calendar (New Style) Act 1750, and in September 1752 the day after the second was the fourteenth. Nobody in that jurisdiction was born on the third to the thirteenth of that month. A record claiming otherwise is wrong, or is in a different calendar, or was made somewhere else.
Every switching country has a run of dates like that, and the run differs for each. One country reversed course partway through a gradual reform and produced a thirtieth of February in the process, a date that existed exactly once.
Dates the calendar never has
| Date | Why it cannot exist | How it gets into a record |
|---|---|---|
| 31 April, 31 June, 31 September, 31 November | Those months have thirty days | Day and month swapped in transcription; the impossible result is the tell |
| 30 or 31 February | February has 28 or 29 | A day-of-year offset applied twice |
| 29 February in a common year | No leap day that year | A leap-day birth copied into the wrong year, or a year error hiding behind a plausible day |
| Any date in a removed run | Those days were skipped in that jurisdiction | A Julian date treated as Gregorian, or a date copied from a source in another country |
| A date before the calendar existed | Back-projected dating | A historical date converted without saying so |
Building the check
Data validation for a birth date is a short list of rules, and the interesting ones are the last two.
- The month is one to twelve.
- The day fits the month.
- The leap rule matches the calendar the record is in: every fourth year for a Julian record, the century exception for a Gregorian one.
- The date was not removed in the jurisdiction of the record.
- The calendar assumed in rule three was actually in force at that place and time.
Rules four and five need the place, and the place is what most lists drop first. A validator that runs without it passes dates that should fail. That is the ordinary state of most large birthday databases.
What a failed check tells you
An impossible date is not a bad row to delete. It is evidence about how the row was made. A swapped day and month says the record passed through a system with a different date order, and every other row from that source may have been swapped wherever the swap produced a valid date. A date inside a removed run says the source was in the Julian calendar, so every other date from it is offset too. A 29 February in a common year says the year is wrong, and the year is what an age is computed from, so the arithmetic on the July page is wrong for that entry as well.
Keep the failed rows. Log the rule each one failed. Then go back to the source and look at its valid rows with the same suspicion, because a source that produced one impossible date produced possible-looking wrong ones too.
Why this rarely gets done
It needs the jurisdiction and the calendar of the record, and neither is a field most lists carry. The January index asks for a date type; the August page asks for the calendar; the April page explains why the place of registration may not be where the birth happened. Put those fields on an entry and the checks above become possible. Leave them off and the index can only confirm that the digits look like a date, which is all it has ever done.
Common questions
How many people does the 1752 gap affect?
Nobody living. It affects records, and through records it affects any historical entry on a page like this one that was copied from a source that never stated its calendar.
How common is a swapped day and month?
Very, wherever records cross between systems that order the two differently. It goes undetected whenever both numbers are twelve or under, which is more than a third of all dates.
Should an index reject an entry with an impossible date, or hold it?
Hold it, marked, with the rule it failed. Rejecting it loses the tracer. March explains the drift that made the removed days necessary in the first place.