After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 125267 - Dates in calendar incorrect prior to September 14, 1752.
Dates in calendar incorrect prior to September 14, 1752.
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkCalendar
unspecified
Other Linux
: Normal enhancement
: Medium feature
Assigned To: gtk-bugs
gtk-bugs
: 131477 155950 540476 (view as bug list)
Depends on: 113319
Blocks:
 
 
Reported: 2003-10-23 05:47 UTC by Paul Bryan
Modified: 2014-05-23 10:46 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Paul Bryan 2003-10-23 05:47:59 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
Comment 1 Mark McLoughlin 2003-10-23 10:15:31 UTC
You must be kidding :-)

Moving to gtk+ - the bug would be in GtkCalender
Comment 2 Matthias Clasen 2003-10-23 10:37:14 UTC
While GtkCalendar doesn't use GDate currently, I guess the discussion 
in bug 113319 is relevant to this. 
Comment 3 Owen Taylor 2003-10-29 20:56:36 UTC
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.)
Comment 4 Matthias Clasen 2004-01-15 14:20:42 UTC
*** Bug 131477 has been marked as a duplicate of this bug. ***
Comment 5 Matthias Clasen 2004-01-15 14:24:17 UTC
I've created a bug for "switch GtkCalendar to GDate" now, bug 131562
Comment 6 Linus Walleij 2004-01-16 11:59:16 UTC
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".
Comment 7 Matthias Clasen 2004-01-16 12:05:35 UTC
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.
Comment 8 Linus Walleij 2004-01-16 12:37:04 UTC
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.
Comment 9 Vincent Untz 2004-10-27 18:48:40 UTC
*** Bug 155950 has been marked as a duplicate of this bug. ***
Comment 10 Matthias Clasen 2008-06-29 06:29:45 UTC
*** Bug 540476 has been marked as a duplicate of this bug. ***
Comment 11 Matthias Clasen 2014-05-23 10:46:56 UTC
closing out old bugs