4 ms·

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.

by tzury 1y ago

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

ghurtado 1y ago
> 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.
- Waraqa 1y ago
  I assume an integer field is sufficient since mostly it's only the year that they know not the exact date.
  - brazzy 1y ago
    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.
    - kragen 1y ago
      Mostly true, but not absolutely: https://en.wikipedia.org/wiki/Varronian_chronology 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]
    - kehvyn 1y ago
      I actually looked at supporting dates like this, but if you go through the Met's open dataset (https://github.com/metmuseum/openaccess 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"
  - Atlas667 1y ago
    Text is better together with specific formats like Circa, ranges, exact years or dates, and unknown.
- lazide 1y ago
  Turing complete DSL, here we come!
- rossant 1y ago
  Tiny language model.
- jacquesm 1y ago
  That's got to be a study in exceptions. Let's start with which calendar we're referencing. C14 anybody?
- tzury 1y ago
  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.
- kehvyn 1y ago
  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 https://github.com/kjrocker/epochal
divbzero 1y ago
> 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.
- ralferoo 1y ago
  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.
- wvbdmp 1y ago
  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…
scrollaway 1y ago
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.

by tzury 1y ago

ghurtado 1y ago

> 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.

Waraqa 1y ago
I assume an integer field is sufficient since mostly it's only the year that they know not the exact date.
- brazzy 1y ago
  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.
  - kragen 1y ago
    Mostly true, but not absolutely: https://en.wikipedia.org/wiki/Varronian_chronology 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]
  - kehvyn 1y ago
    I actually looked at supporting dates like this, but if you go through the Met's open dataset (https://github.com/metmuseum/openaccess 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"
- Atlas667 1y ago
  Text is better together with specific formats like Circa, ranges, exact years or dates, and unknown.
lazide 1y ago
Turing complete DSL, here we come!
rossant 1y ago
Tiny language model.
jacquesm 1y ago
That's got to be a study in exceptions. Let's start with which calendar we're referencing. C14 anybody?
tzury 1y ago
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.
kehvyn 1y ago
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 https://github.com/kjrocker/epochal

divbzero 1y ago

> 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.

ralferoo 1y ago
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.
wvbdmp 1y ago
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…

scrollaway 1y ago

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.