GNOME Bugzilla – Bug 113319
g_date_is_leap_year wrong for years prior to 1752
Last modified: 2013-10-25 05:17:25 UTC
Before 1752 the Julian calendar was used, which knew only the rule that leap years are all years that are dividable by four. The attached patch fixes this problem.
Created attachment 16650 [details] [review] patch that fixes this problem
From what I can quickly dig up on the web, it's a good bit more complicated than that; leap years were adopted in 1752 for Britain and colonies, but at a different time for the rest of the world; and prior to 1752 there was already a leap year system in place, it was just slightly different. Some info here for example: http://developer.postgresql.org/docs/postgres/units-history.html To really get all the history right I think you have to change more than just this one place; e.g. g_date_update_julian() looks like it needs changing. Anyway, from what I remember the plan with gdate was to ignore historical oddities and just run the straightforward date algorithms, but it was 5 years ago when I last actively thought about the plan, so I could remember wrong.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/GregorianCalendar.html Is what Java does; the default value of the cutover date is locale dependent. The equivalent .NET class is: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemglobalizationgregoriancalendarclasstopic.asp I believe that you are supposed to simple simply pick between JulianCalendar and GregorianCalendar yourself. If that's right, that would mean that the behavior of the methods in System.DateTime http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdatetimeclasstopic.asp is the same as GDate currently. My opinion on this issue: - The current behavior has some benefit of simplicit - Using a fixed cutover date would get things "right" for prior to 1578 automatically, but is that worth an quasi-incompatible API change? - It's basically going to have to be configurable if you want to be able to use GDate to answer questions like "on what day of the week was Charles I" executed. (Julian Date Junuary 30, 1649 == Gregorian Date February 9, 1649, a Tuesday. )
That Java link says: "GregorianCalendar implements proleptic Gregorian and Julian calendars. That is, dates are computed by extrapolating the current rules indefinitely far backward and forward in time." So Java is also doing the GDate thing. I don't think we can change what GDate does without more comprehensively addressing the issue (making GDate tunable for different calendars and locales).
You cut your quote too short, and omitted the part that made it clear that it is the Julian calendar which is extended back indefinitely. "...However, dates obtained using GregorianCalendar are historically accurate only from March 1, 4 AD onward, when modern Julian calendar rules were adopted. Before this date, leap year rules were applied irregularly, and before 45 BC the Julian calendar did not even exist." So, it does try to handle some 1600 years of dates more correctly than GDate. But I'd agree that with the current API's, keeping GDate strictly proleptic Gregorian makes the most sense. (Hence the API/future classification of the bug)
Changed the severity to "enhancement" because of the issues involved.
GDate is deprecated for favour of GDateTime and GDateTime is explicitly proleptic (ie: we pretend that we always had a Gregorian calendar), so we won't fix this now.