HN Reader

This isn't just the oldest recorded transaction, it's nearly the oldest known recognizable sample of human writing. Not a love letter or a sermon or a story, but a receipt. This probably reflects their ubiquity rather than importance. There is one known older writing sample, the Kish Tablet of Jemet Nasr. Since that tablet represents lists and counts of goods (barley, oil, livestock), it may also be a receipt, or perhaps an inventory.

The oldest known non-commercial writing is a set of proverbs from around 2600 BCE, Instructions of Shuruppak.

With my luck my most cringe-worthy diary entries will probably last that long.

> 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? Use some custom system? How do I get it to support all the custom operations that a typical TIMESTAMP supports?

Think about how the museum physical text book store it, as simple text with processing offloaded to the reader (ie: circa 4000BC, Before 2000BC, After ...)

I wonder, if for some problems, we'll move to LLM computation instead of a developer coded solution.

Your variables will be

    let date_1 = "2000 BC"
    let date_2 = "3000 B.C."

and when you execute

    if date_1 > date_2 { .. do something .. }

The ">" operator is overloaded to run this operation through an LLM and return True/False.

The idea that artifacts belong forever to whoever inhabits the land today is going to put under increasing pressure as ancient DNA continues to reveal the number and severity of population replacements over time.

You can store whatever ancient timestamp you want in SQLite, its Just Text or Just an Integer although the date library functions may not support it

> Considering this thing survived 5000 years (holy shit!) with zero downtime and has stronger durability guarantees than most databases today.

One could argue that it had 5000 years of downtime when no one knew where it was /s

I think these numerical constraints are because range trees use numerical averages to construct themselves. This is important for OVERLAPS queries common with dates. But you could construct interval tree indexes lexicographically using text but they are quite uncommon. It’s something I’ve experimented with a decent amount though.

https://github.com/ccorcos/database-experiments/blob/master/...

Some more info:

> This tablet with early writing most likely documents grain distributed by a large temple. Scholars have distinguished two phases in the development of writing in southern Mesopotamia. The earliest tablets, probably dating to around 3300 B.C., record economic information using pictographs and numerals drawn in the clay. A later phase, as represented by this tablet, reflects changes in the techniques of writing that altered the shapes of signs. Symbols stood for nouns, primarily names of commodities, as well as a few basic adjectives, but no grammatical elements. Such a system could be read in any language, but it is generally accepted that the underlying language is Sumerian. Indeed, by the first half of the third millennium B.C., the script had sufficiently developed to faithfully represent the Sumerian language, and the scope and application of writing was expanded to include written poetry. Nonetheless, even these later scribes rarely included grammatical elements, and the texts, created as memory aids, cannot be easily read today.

* https://www.metmuseum.org/art/collection/search/327385

* https://en.wikipedia.org/wiki/Jemdet_Nasr_period

I expected there would be constraints, but the chosen range is quite intriguing. The PostgreSQL spec says the 4-byte date type spans 4713 BC to 5,874,897 AD. It gives much more headroom for future dates—did they assume preserving data before 4713 BC is unlikely?

"Six thousand years ago, Sumarians invented writing for transaction processing."... is the first sentence of the "Transaction Processing" book... https://www.amazon.com/Transaction-Processing-Concepts-Techn...

> I call it rock solid durability.

Literally! But this is survivor bias: you only see a piece that remained intact for 5k years, and I bet 99% of them were eroded/destroyed over time.

It might be that tally sticks go back further, maybe "between 44,200 and 43,000"¹ years ago.

so about 42175 BC

:)

[1] https://en.wikipedia.org/wiki/Tally_stick#Possible_palaeolit...

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

Interesting write-up marred by the injection of politics: Maybe if I’m a British Museum manager, and I want to keep -theft- inventory details

Ideological jabs like this are fine in political discussions but they don't add anything elsewhere and serve only to lower the trustworthiness of what is written due to implied bias.

beer drinking goes waaaay back

Me buying a PlayStation 1 in 1997

I'm 52 years old and it has been this way since I can remember but for some reason I can't make it not bug me. Any time we have the biggest/oldest/smallest/fastest/etc example of something, it's described without any qualification of seen, known, observed, etc.

For example, this isn't oldest recorded transaction, it's the oldest widely known record of a transaction (probably).

Why does that still bother me? Obviously nobody is saying it's the oldest recorded transaction, right? That would make it the first recorded transaction, and nobody is calling it that.

And here I am likely triggering your own pet peeve of useless comments on HN. xD

Wow, so much older than the oldest known complaint

https://en.m.wikipedia.org/wiki/Complaint_tablet_to_Ea-n%C4%...

And here's the oldest recorded customer complaint

https://www.thearchaeologist.org/blog/complaint-tablet-to-ea...