upvote
It's typically not used in modern historical writing when referring to events located in areas that used the Julian calendar at that time.

But it is typically used when referring to events located in areas with no calendar system familiar to modern readers, most notably the Maya calendar. Maya Long Count dates are typically converted to the proleptic Gregorian calendar.

Also, many modern historical writings will display both Julian and Gregorian dates, particularly for dates around when the calendars were changing or when context is unclear (e.g. a historical figure who was born in an area with one calendar and died in an area with another calendar).

reply
Considering it only diverges from the standard Gregorian for dates more than 400 years ago, it's not super relevant. Most people don't think about it. But it made a lot of sense to do the shift at the time. All recorded dates up to that point had been physically written down, so it would have been infeasible to migrate those all to the proleptic. If computers had been around, maybe things would have been different.

Fun fact: Greece was still using the old Julian calendar as of 1928, so it's entirely possible that you'll see dates on relatively recent Greek documents that are up to 14 days off from the calendar the rest of the world was using. Civil timekeeping is just a mess.

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

reply
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.
reply
For sure. I was thinking more of "normal" applications, as opposed to things like SQL databases. It looks like the SQL standard explicitly calls for the use of the Gregorian calendar for dates, so I think that answers the previous question of "Who else uses the proleptic Gregorian calendar other than programmers of datetime libraries?"
reply
"normal applications", no. But there are more platforms besides databases, e.g. programming languages. Any platform that works with dates will have to deal with these weird quirks. And application that works with dates probably would not, although there's always leap seconds...
reply
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.

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

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

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

reply
Genealogy apps, e.g. Ancestry.com
reply