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.
> 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.
Fun related fact, many dates -- for example, birth dates on headstones -- of people born in countries observing Eastern Orthodox Christianity will have the prefix O.S. (old style) to disambiguate dates using the original Julian and either the Georgian or Revised Julian calendars which were in effect at that person's death.
A primary reason for the Catholic Church changing the calendar was to bring the date of Easter back into conformance with the decree of the Council of Nicaea on the topic. There was a controversy in the early Church on this, there were even miracles worked concerning the correct date -- see Dom Gueranger's "Liturgical Year" for some of the accounts.
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.
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.
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
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 ==.
This is (weirdly) in line with behaviour I've observed in iOS's date picker; if you set a block of dates as not available, and the selected date inside of that unavailable block, it will automatically select the first available date on open.
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)?
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.
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.
Contracts and other similar types of financial instruments existed by this time there must be some way they handled it because something that said that it happened on a date that never occurred - sounds like what lawyers live for.
I’ll draft a Dubia so that when future popes change the calendar they will include a representative code sample and details about how we handle this.
(It’s important to remember that the pope and friends were operating much more like an international standards body than a religious leader when doing things like this.)
If a contract dated to the 4th October 1582 specifies you have 15 days to make payment, you would indeed need to know where that contract was signed to determine on what day that deadline expired.
And if there is a contract dated to the 6th October 1582, that does raise questions about its legitimacy (though in general misdating a contract does not void it, it would merely be one point of evidence in your argument that it's a forgery, just like using a particular font in a modern printed contract)
Think it depends on usage? Taking October 1st and 20th, and you want to know how many days passed, what's the right answer? If it's days lived, you would want the answer to not be 20, as some of those days didn't happen. But in some other context (perhaps something transitioning to the calendar earlier), they did?
'A date object represents a date (year, month and day) in an idealized calendar, the current Gregorian calendar indefinitely extended in both directions.'
'This matches the definition of the “proleptic Gregorian” calendar in Dershowitz and Reingold’s book Calendrical Calculations.'
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
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.
Is the stack trace in the Ruby transcript invisible for anyone else? It seems to show up as white text on a white background.
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.
> 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
Fun related fact, many dates -- for example, birth dates on headstones -- of people born in countries observing Eastern Orthodox Christianity will have the prefix O.S. (old style) to disambiguate dates using the original Julian and either the Georgian or Revised Julian calendars which were in effect at that person's death.
A primary reason for the Catholic Church changing the calendar was to bring the date of Easter back into conformance with the decree of the Council of Nicaea on the topic. There was a controversy in the early Church on this, there were even miracles worked concerning the correct date -- see Dom Gueranger's "Liturgical Year" for some of the accounts.
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/
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.
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 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:
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 tried to create a date object in Swift from the date October 5, 1582. The resultant date object was October 15th 1582.
This is (weirdly) in line with behaviour I've observed in iOS's date picker; if you set a block of dates as not available, and the selected date inside of that unavailable block, it will automatically select the first available date on open.
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.
> https://en.wikipedia.org/wiki/List_of_non-standard_dates#Feb...
Meta: one can also link to this article, which redirects:
* https://en.wikipedia.org/wiki/February_30
But that redirect (intentionally or not) doesn't include the fragment part of the URL, so it might not have satisfied the other poster's intent.
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.
Contracts and other similar types of financial instruments existed by this time there must be some way they handled it because something that said that it happened on a date that never occurred - sounds like what lawyers live for.
I’ll draft a Dubia so that when future popes change the calendar they will include a representative code sample and details about how we handle this.
(It’s important to remember that the pope and friends were operating much more like an international standards body than a religious leader when doing things like this.)
If a contract dated to the 4th October 1582 specifies you have 15 days to make payment, you would indeed need to know where that contract was signed to determine on what day that deadline expired.
And if there is a contract dated to the 6th October 1582, that does raise questions about its legitimacy (though in general misdating a contract does not void it, it would merely be one point of evidence in your argument that it's a forgery, just like using a particular font in a modern printed contract)
Think it depends on usage? Taking October 1st and 20th, and you want to know how many days passed, what's the right answer? If it's days lived, you would want the answer to not be 20, as some of those days didn't happen. But in some other context (perhaps something transitioning to the calendar earlier), they did?
The proper name for the calendar using the Gregorian system before the start of the Gregorian calendar is "the proleptic Gregorian calendar".
And indeed that's Python's calendar:
'A date object represents a date (year, month and day) in an idealized calendar, the current Gregorian calendar indefinitely extended in both directions.'
'This matches the definition of the “proleptic Gregorian” calendar in Dershowitz and Reingold’s book Calendrical Calculations.'
https://docs.python.org/3/library/datetime.html#id2 https://docs.python.org/3/library/datetime.html#id5
Whereas Ruby has proleptic Gregorian Time, but civic DateTime:
https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime....
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
Ok now do date math, does the day-of-month accurately jump over the non-existent numbers?