Item — HN Reader

Quote:

    I wonder how people store dates older than this. 
    
    Maybe if I’m a British Museum manager, and I want to keep theft inventory details. 
    
    How do I do it? As an epoch? Store it as text?

The answer: Text.

Many items in museums have no specific date but Circa X. I have spent a lot of time in the early 2000s to enable "Sort by date" in museum registrars software I was maintaining despite having it textual

3 comments

> Sort by date" in museum registrars software

This sounds like the perfect invitation for some old school over engineering.

I'm already having so much fun running through every possible input in my head, and I would inevitably write a serious mountain of steaming code to support it.

I simply built a side table in the DB, whereas any expression was associated with a range of a 2 YEARS (numbers).

any time they enter and expression (auto complete), it they introduce a new one, they needed to add the range.

this did the job.

the time I spent the most was to sort the existing data and restore it in the new dictionary.

I've actually done this, and it's very fun.

My main testing dataset is the 470,000 records from the Met, with 33k unique date values. Fortunately they include machine-readable dates I can validate against.

https://github.com/kjrocker/epochal

That's got to be a study in exceptions. Let's start with which calendar we're referencing. C14 anybody?

I assume an integer field is sufficient since mostly it's only the year that they know not the exact date.

No, you need a lot more complexity if you really wanted to represent it semantically. The assumption that people in the past used calendars with sequentially numbered years you just need to offset, is simply wrong.

You have things like "in the Xth year of the reign of King Y", where we can easily relate multiple entries with different values for X, but don't actually know which CE years they correspond to. Even weirder is the Roman habit of recording "the year of the consulship of X and Y", which doesn't even allow you to relate any two different years at all without a reference table (which we don't have completely). And no, "years from the foundong of the city" wasn't a thing.

I actually looked at supporting dates like this, but if you go through the Met's open dataset (https://github.com/metmuseum/openaccess) that kind of "alternative calendar with no reference to the BCE/CE dates" is basically nonexistent.

There are references to the Islamic and Japanese calendar systems, but always next to the CE equivalent.

Data entry is fortunately being done by modern people, so the translation to CE/BCE is usually baked in, and all you need to support is every possible way somebody could say "the early half of" and "5th millenium B.C. to mid 1914"

Mostly true, but not absolutely:

https://en.wikipedia.org/wiki/Varronian_chronology

> The Varronian chronology was adopted by the Roman state during the first century BC and gave rise to the traditional years ab urbe condita ("from the founding of the city"); most especially, those dates were used in monumental Augustan-era inscriptions, the fasti Capitolini and the fasti Triumphales.[40]

Text is better together with specific formats like Circa, ranges, exact years or dates, and unknown.

Turing complete DSL, here we come!

Tiny language model.

I think the world could use an “imprecise” data type, which would be a tuple (t, margin).

In your case: if you wanted a date plus minus 50yrs, that would be (date(d), range(years, 50)).

Some construction like this allows for I believe most use cases. You just need to be able to store: date, date time, date range, and the precise/imprecise versions of all of these.

> The answer: Text.

That was my immediate thought too and led to me wondering: How do you represent BCE dates in ISO 8601?

Apparently ISO 8601 always supports YYYY from 0000 (1 BCE) to 9999 (9999 CE). ISO 8601 can also extend beyond those limits if agreed upon by sender and receiver: e.g. -0001 (2 BCE), -0002 (3 BCE), etc.

Hopefully nobody uses this "standard" that bakes in an off-by-one error into the human readable form.

IMHO if code is doing extra parsing to handle -ve years, they should have enough logic to know to how to skip the zeroth year when converting to and from the human readable form.

Okay… someone please steelman this seemingly unhinged decision.

edit: Apparently that’s how they do dates in astronomy since it makes the math easier. Can’t even count on years being gregorian these days…