HN Debrief

Dates That Don't Exist (2015)

  • Programming
  • Infrastructure
  • History
  • Developer Tools

The post shows a classic calendaring trap: when Pope Gregory XIII introduced the Gregorian calendar in 1582, some places skipped a block of dates to realign the calendar, so labels like October 10, 1582 did not exist in those jurisdictions. It then compares language behavior and treats libraries that accept such dates without complaint as getting history wrong. The strongest correction is that this only makes sense if you mean a specific civic calendar for a specific place. Most programming languages and date libraries deliberately use the proleptic Gregorian calendar, which extends today’s Gregorian rules backward indefinitely and treats those dates as valid. That is not a bug. It is a design choice that keeps arithmetic consistent and avoids embedding every country’s adoption history into the default date type.

If your product stores or compares historical dates, you need to pick a calendar model explicitly instead of assuming the standard library matches user expectations. For most software, proleptic Gregorian plus clear documentation is fine, but archival, genealogy, legal, and history-heavy systems need jurisdiction-aware rules or custom calendar handling.

Discussion mood

Mostly corrective and mildly skeptical of the article’s framing. People liked the historical oddities, but the dominant reaction was that the post treats a niche historical calendar issue as a universal bug when most libraries are intentionally modeling a different abstraction.

Key insights

  1. 01

    Calendar cutovers are local policy

    Handling the Gregorian switch correctly means choosing whose switch you mean. A date like 1582-10-10 can be invalid in one civic calendar and perfectly valid in another representation of the same period. The practical point is that a default date type cannot encode history without also encoding jurisdiction, and sometimes even religious or institutional practice.

    If users enter historical dates, collect the place and calendar assumption at input time. Without that metadata, your system cannot reliably tell whether a date is invalid, ambiguous, or merely expressed in a different convention.

      Attribution:
    • deathanatos #1
    • bloppe #1
  2. 02

    Proleptic Gregorian is an intentional default

    Libraries like Perl DateTime and Python are not accidentally accepting impossible dates. They are explicitly using the proleptic Gregorian calendar because it gives one continuous rule set for parsing and arithmetic. The article’s complaint about missing errors falls apart once you read the docs and accept that the type is modeling an idealized calendar, not country-specific history.

    Treat pre-1582 behavior as part of your dependency contract. Read the library docs before building validation rules or cross-language comparisons around historical dates.

      Attribution:
    • autarch #1 #2
    • flotzam #1
    • throwawayk7h #1
  3. 03

    Historical dates are niche until they are not

    Pre-1582 and cross-calendar handling sounds academic until you hit databases, library catalogs, genealogy products, knowledge bases, or astronomy. SQL platforms may need broad year support. Archival systems store manuscript dates as recorded. Wikidata-style systems need conversion across calendars. The edge case becomes real as soon as your platform promises general date support rather than one product workflow.

    Audit whether you are writing an application or a platform. Platform code should document its calendar model early, because downstream users will eventually hit cases you thought were too obscure to matter.

      Attribution:
    • bloppe #1
    • philjohn #1
    • tshaddox #1
    • paulddraper #1
    • ks2048 #1
  4. 04

    Date labels and elapsed time are different problems

    Several comments sharpened the core modeling issue. A historical date label is not the same thing as an elapsed-time measurement. Proleptic calendars are great for consistent arithmetic, but they can misrepresent what contemporaries called that day. Civic calendars can preserve historically used labels, but then arithmetic across cutovers and odd cases like Julian leap days becomes awkward fast.

    Separate APIs for human-facing date labels and machine-facing durations or instants. You will avoid a lot of false assumptions if the type system makes that distinction obvious.

      Attribution:
    • russdill #1
    • da_chicken #1
    • wduquette #1
    • cjm42 #1
  5. 05

    Dates are names, not instants

    One commenter gave the most useful general abstraction: calendar dates are human naming schemes mapped onto underlying moments or spans of time, and those mappings can be missing or ambiguous. That puts skipped Gregorian dates in the same family as daylight saving time gaps and overlaps. It also explains why future date calculations are partly speculative when rules can change.

    Store unambiguous instants when the business meaning is about sequence or timing. Preserve the original date string and calendar context when the business meaning is about how humans named the event.

      Attribution:
    • zanecodes #1
    • madcaptenor #1
  6. 06

    Composite calendars are the real fix

    A concrete implementation idea emerged from the Elixir Calendrical library. Instead of forcing one calendar everywhere, it splices multiple calendar segments at historical cutover dates so a country-specific calendar behaves like one object. That lets date validation and date arithmetic both respect the actual jump, such as England’s 1752 switch and its earlier March 25 new year.

    If historical accuracy is a product requirement, stop stretching generic date types past their design. Build or adopt a composite calendar model with explicit cutover tables.

      Attribution:
    • kipcole9 #1

Against the grain

  1. 01

    Secondary sources should not mimic old calendars

    For general historical writing, using the date people actually recorded at the time can create more confusion than clarity. Most readers benefit from a normalized modern calendar, just as they benefit from translated names and standardized year numbering. The historical label matters most when quoting primary sources or doing source-critical work.

    If your product is educational or consumer-facing, prefer one normalized display convention and expose original calendar dates as metadata. That gives readers consistency without throwing away provenance.

      Attribution:
    • Asraelite #1
    • da_chicken #1
  2. 02

    Pass timestamps, not multipart dates

    One commenter pushes the engineering view to its logical end. Internal systems should mostly operate on numeric epochs, not free-form or multipart date fields, because human-readable dates can be internally inconsistent before you even reach historical corner cases. Calendar logic belongs at input and output boundaries unless the domain truly needs date semantics.

    Review APIs and storage formats for places where you are passing calendar fields around unnecessarily. Replacing them with timestamps or canonical instants can eliminate an entire class of bugs.

      Attribution:
    • ptaffs #1

In plain english

civic calendar ↩
The calendar rules actually used by a government or society at a given time and place for everyday legal and civil dates.
cutover ↩
The date when a region or system switches from one calendar or timekeeping rule set to another.
DATETIME ↩
A database field type used to store calendar date and time values.
Gregorian calendar ↩
The calendar system introduced in 1582 to correct the Julian calendar’s drift, and now the standard civil calendar in most of the world.
proleptic Gregorian calendar ↩
The Gregorian calendar extended backward to dates before it was historically introduced, using the same leap-year rules throughout.
SQL ↩
Structured Query Language, the standard language used to define and query relational databases.
Wikidata ↩
A collaborative structured knowledge database used by Wikimedia projects and others.

Reference links

Calendar background and adoption history

Programming language and library behavior

Historical oddities and deeper reading