GNOME Bugzilla – Bug 166465
Year may be zero or negative.
Last modified: 2018-04-15 00:35:31 UTC
Please describe the problem: The year may be zero or negative. There was never a year zero and negative years should be positive with a BC suffix. Steps to reproduce: 1. Click the Clock applet. 2. Change the year backwards. Actual results: The year will eventually get to zero and negative years. Expected results: The zero is skipped and negative years are positive with a BC suffix. Does this happen every time? Yes. Other information: While zero and negative years are used in the ISO 8601 version of the Gregorian calendar, that usage is focused around astronomy. Astronomers do not seem to be a target audience of Gnome. See http://en.wikipedia.org/wiki/ISO_8601 and http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar as references.
Created attachment 84839 [details] [review] A patch to change the calendar's year behaviour This patch changes the calendar's year behaviour. Year 0 now becomes 1 BC, and negative years are represented as (-1*X + 1) BC. A new display option defined, as GTK_CALENDAR_YEAR_ASTRONOMICAL, which reverts the calendar widget to astronomical year numbering, which was its default behaviour. References: http://en.wikipedia.org/wiki/Astronomical_year_numbering
I rather think that GtkCalendar allowing year being <= 0 is a "visual" glitch, as it doesn't allow setting/getting years below 0 API-wise (note the guint year parameter), so I think it should just set the relevant arrows insensitive.
Fair point, I didn't check the setting/getting function when creating this patch. Perhaps this is another bug, because depending on the calendar's widget's usage, years <=0 may be important. For example: an astronomical application, where someone could want to see what the stars were doing on a particular date, then the calendar should allow to go below 1 AD. Same thing could go for a historical application. (Don't know of any projects that need these at the moment tho) Perhaps the default behavior should be changed, and allow options to have both the ISO 8601 and non ISO 8601 behavior for <=0 years?
*** Bug 362972 has been marked as a duplicate of this bug. ***
*** Bug 603179 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new