GNOME Bugzilla – Bug 125267
Dates in calendar incorrect prior to September 14, 1752.
Last modified: 2014-05-23 10:46:56 UTC
The clock applet does not take into consideration the loss of 11 days in September, 1752. After Wednesday, September 2nd came Thursday, September 14th. The clock applet shows September 3rd through 13th, skewing dates prior to September 14th by 11 days. To see the proper behavior, run "cal 9 1752" in a modern UNIX environment. It should read: September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 For background information on this issue: http://www.google.ca/search?q=september+1752
You must be kidding :-) Moving to gtk+ - the bug would be in GtkCalender
While GtkCalendar doesn't use GDate currently, I guess the discussion in bug 113319 is relevant to this.
Since GtkCalendar is a user thing, I think the ideal behavior is to make a best guess of the Julian/Gregorian cutover for the user's location and display based on that. Naturally, this is a) hard to do b) low priority. You'd also have to figure out the API implications -- does it return the MDY that the user selected or the proleptic (continued backwards) Gregorian date that corresponds. The API implications presumably would depend on what we did for gdate for bug 113319, and you'd also want to switch GtkCalendar over to using GDate first. (I thought there was a bug about that open, but I don't see it.)
*** Bug 131477 has been marked as a duplicate of this bug. ***
I've created a bug for "switch GtkCalendar to GDate" now, bug 131562
I feel I have to clarify that this is a real issue. America obviously switched over from julian to gregorian calendar in 1752, and this may seem ancient and irrelevant, but to certain tools like geneaology programs, it is a real issue. For example Gramps (http://gramps.sourceforge.net) cannot use the calendar to check what days are available in a certain month. Also, you have probably not fully understood the scope of this issue from an i10n perspective, for example Russia is a big issue: this country used the julian calendar up to 1918, and this brings the issue considerably closer in time. That is the reason to why the so-called "October revolution" occured in November, according to our gregorian calendar. Thus all calendar amendments *must* be locale-dependent. In Sweden the situation is even more delicate: prior to the year 1700 we used the julian calendar. On february 1700 (which is a leap year according to the julian calendar) the leap day was removed as a movement toward the gregorian calendar. The removal of leap days was stopped, however, so Sweden has a unique modified julian calendar 1700-1712. In 1712 we went back to the julian calendar by introducing 30 (!) days in february. Julian calendar was then used 1712-1753 when we finally switched to gregorian, by making february 1753 only 17 days long. After this, Sweden follows the gregorian calendar. I believe we (Sweden) may have the most complicated calendar on this earth, but in applications like geneaology it really matters. And indeed, a switch to GDate is the first logical step. Then a lot of locale code must be added, possibly altering the calendar substantially. I will be happy to help out with the Swedish part after the GDate switch has been done. I request that you raise the severity of this bug to atleast "minor".
Well, you could start working on an API proposal/implementation for GDate to support non-Gregorian calendars independent from switching GtkCalendar over. First step would probably be to review how other frameworks support this: Java, Windows, ICU (?), cal.
GDate already support both julian and gregorian calendars as abstract entities, so that is firm infrastructure. As to locale deviations, I believe these are to go into GtkCalendar, as GDate explicitly only provides gregorian and julian calendars. No interface changes needed there IMO. GNU cal (http://www.gnu.org/directory/GNU/gcal.html) already has a very good (and cool) calendar implementation that takes care of these issues. Running gcal with for example: gcal --gregorian-reform=1753 1753 will procude a correct Swedish calendar for 1753 (though it'll be erroneous for 1700-1712). Actually the data and experience (presumably) painfully collected in GNU cal should probably simply be reused for the GtkCalendar locale-dependent code.
*** Bug 155950 has been marked as a duplicate of this bug. ***
*** Bug 540476 has been marked as a duplicate of this bug. ***
closing out old bugs