It’s funny to see this on HN. I wrote this 11 years ago as an undergraduate.

The afternotes at the end of the post are worth reading; people have sent me various qualifications and corrections over the years.

> In essence, then, those ten days in 1582 never happened and simply do not exist within the Gregorian calendar system used almost universally in the West today.

I find these things so much easier to think about if you consider the change as a change from one calendar system to another calendar system. Those 10 days certainly exist, in both calendar systems, they just represent different points in time. I.e., I think it's easier to just consider both calendar systems as the rules, extended forward & backwards infinitely ("proleptic"). Some people switched from a Julian calendar to a Gregorian one in 1582.

"Some people did not experience days with these labels in some areas of the world" … I get where it's coming from, but it's not how I'd build a library.

If you worry about the switch, then you have to ask "which switch?" which TFA only lightly touches on. The 1582 one is famous, of course, but not everyone switched, and other parts of the worlds switched as time went on, to as late as 1918, when Russia switched.[1] (And you can see other messiness in that table, too.)

Needing to deal with it is niche enough that I think most language std libs should implement the proleptic Gregorian calendar, and let an application whose niche requires it deal with the switch (& whichever switch it requires).

[1] https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_...

There seems to be disagreement about the year.

(OpenBSD) $ man cal [...] The Gregorian Reformation is assumed to have occurred in 1752 after the 2nd of September. By this time, most countries had recognized the Reformation (although a few did not recognize it until the early 1900s). Eleven days following that date were eliminated by the Reformation, so the calendar for that month is a bit unusual.

(Ubuntu Linux) [...] -s country_code Assume the switch from Julian to Gregorian Calendar at the date associated with the country_code. If not specified, ncal tries to guess the switch date from the local environment or falls back to September 2, 1752. This was when Great Britain and her colonies switched to the Gregorian Calendar.

The article is a bit old. It should have noted a new development in calendar technology if it was written half a year later.

> In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead.

https://lwn.net/Articles/669022/

> The Eastern Orthodox church even continued well after that, only switching to the Gregorian calendar in 1929.

Technically, they switched to the Revised Julian[0] calendar, not the Gregorian. Also, it was only some of the churches making up Eastern Orthodoxy that switched; others remain on the Julian calendar to this day, and all of them still use the Julian calendar to calculate the date of Pascha.

[0] https://en.wikipedia.org/wiki/Revised_Julian_calendar

This is clearly the wrong way to think about it. Dates forward and backward from this flag date exist in both calendars and it's straightforward to convert between them.

Such a flag day didn't involve removing days from one calendar or the other, it switched between them.

Dates really are a headache.

In our Dip (in house db) client library, we built what we called a policy that auto selects partitions based on every crud operations. The policies can be specified once for each collection in collections.json based on fields or query.

So for policies where partition involves the date type fields, be it range or fixed dates, it was incredibly hard to generate universal date names from ranges.

The policy mechanism was finished fairly quickly as Dip is inherently distributed first. But reasoning about date names was so incredibly hard.

The missing dates mentioned in the article did come up during development adding to the woes.

But the upside now is that application code no longer worries about the distributed partitions. Policy handles that. Some sort of architecture as code. Don't know whether AAC is an existing term or whether we coined it.

I tried to create a date object in Swift from the date October 5, 1582. The resultant date object was October 15th 1582.

Are we really supposed to trace this given how ancient it is? If we really want to do far we would eventually reach ancient Chinese emperor era names that even confuse historians

I wonder how many libraries correctly handles the date 1712-02-30 in the Swedish calendar (according to Wikipedia the only official 30th of February in history)?

https://en.wikipedia.org/wiki/List_of_non-standard_dates#Feb...

Tried using ncal like in the examples in that blog post, but it did not work correctly using either Julian or Gregorian. Of course the Swedish calendar from 1700-1712 was neither, but somewhere in-between, because of the (failed) attempt to gradually move from one to the other.

Is the stack trace in the Ruby transcript invisible for anyone else? It seems to show up as white text on a white background.

I ran into this in a Ruby on Rails test suite a few years ago and wrote up my findings here: https://gist.github.com/abachman/f97806e1c0fe8e4e1849e5f8412...

tl;dr - ActiveSupport::TimeWithZone used absolute seconds counting to determine dates while DateTime used a proper Gregorian calendar. This means dates before October 15, 1582 have different internal values when compared.

The behavior showed up because a test was using a DateTime value to set a MySQL DATETIME column to the DB minimum value, which is 1000-01-01 00:00:00, and then comparing the DB record attribute to the original variable used to set it.

Something like:

  date = DateTime.new(1000, 1, 1, 0, 0, 0, 'UTC')
  record.update(happened_at: date)
  record.happened_at == date # => false

I "discovered" the missing Gregorian dates when I wrote a loop counting forward in time from Jan 1, 1000 until the corresponding TimeWithZone and DateTime records returned true when compared with ==.

I suppose the Georgian calendar includes this gap officially? Or did the catholic world just jump from system to system? If it includes the gap officially, then yea, error is the right thing. But if we just moved to a new calendar, then arguably there should be no error. both calendars work for all dates continuously, and we could have conversion functions etc. The gap is just a big flag day (week.)

imo, if i am using Georgian i want that system even retroactively, just like projecting a date back into the stone age. I don't care that a particular geography or culture changed calendars.

So I suppose what is really going on is that some libraries are using Georgian consistently, and others are using some hybrid "civic" calendar that tracks what the romans and the catholics were using, so dates in history books make sense.

Regarding computers and time, I always liked that in AmigaDOS, you could specify custom relative times.

It would natively display "Future" if the file timestamp was ahead of the system clock, but you could also add dates. I remember seeing directory listings like

  xyzzy.foo 49152 ----rw-d Christmas 1988

Ok now do date math, does the day-of-month accurately jump over the non-existent numbers?

[dead]