logoalt Hacker News

autarchtoday at 4:46 PM8 repliesview on HN

Who writes computer programs that deal with pre-1582 _dates_ at all?

In science-related code, I can image a case for calculating things like seconds elapsed across a very long time period. But in that case you're not really dealing with dates. Instead, you want something like the Unix epoch, but probably with an earlier epoch start.

There may be some very niche cases for pre-1582 dates in code that I'm not thinking of. But I'd expect that in this case you're going to put a lot of effort into finding the right libraries, or you might just write your own code.

Regardless, the linked blog post says of DateTime: "Unfortunately, like Python, a proper error message for impossible Gregorian dates is notably absent."

But this is just wrong. There's no "proper error message" to emit. The code works as documented.


Replies

bloppetoday at 4:52 PM

Most applications don't have to worry about it, but platforms do. The SQL standard requires accurate date representation for years 0000-9999. I was surprised to learn about the Gregorian shift while testing our database system. I also learned about "war time" in WW2 and the "battle of the clocks" in colonial India. A lot of history came out of debugging those tests.

show 1 reply
philjohntoday at 7:34 PM

Library and Archival management systems

Lots of written work pre 1582 that needs to be accurately catalogued.

Source: I used to work on one of the first computerised library management software systems, and plenty of our academic customers had manuscripts dating back that far.

tshaddoxtoday at 4:56 PM

> Who writes computer programs that deal with pre-1582 _dates_ at all?

People writing knowledge base software, like Wikidata. It's helpful to be able to display historical dates in any desired calendar, and also to be able to do date arithmetic between any two arbitrary dates.

ptaffstoday at 6:25 PM

This point about using seconds is entirely correct, and date-time should always be in epoch timestamp (numeric) except for human interfaces (input or rendering for output). APIs and web-forms should never pass multipart date strings because they can be internally inconsistent, for example February 30. (edit: unless there's no sequential meaning in the date and the date is just a local day name without the notion that adding or subtracting 1 takes you to yesterday or tomorrow (https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...)).

(p.s. autarch thanks for your efforts in open source).

tomjakubowskitoday at 9:44 PM

Genealogical software, historical video games (CK2 has at least one mod which adds alternative calendars), I can imagine there are some needs for this in contract management software for countries with very old businesses and properties like England and Japan.

ks2048today at 7:56 PM

I've been writing some programs to deal with the Maya Calendars, where it is an issue.

On some level, it doesn't matter if an inscription corresponds to "August 31, 83 CE" or "September 2, 83 CE" (a date potentially inscribed at the site Takalik Abaj in Proleptic Gregorian or Julian), but it's nice to try to get the details correct. And if you want to correlate with other events in history (especially if you can find astronomical event data from Europe), you need to be at least consistent.

Plus, it's just fun to think about these events from long ago in terms (dates) we understand.

ButlerianJihadtoday at 7:24 PM

Astronomy

show 1 reply
paulddrapertoday at 7:21 PM

Genealogy apps, e.g. Ancestry.com