[Development] Calendar Systems proposal
soroush.rabiei at gmail.com
Fri Dec 16 00:24:39 CET 2016
On Thu, Dec 15, 2016 at 3:53 PM, Edward Welbourne <edward.welbourne at qt.io>
> Soroush Rabiei wrote:
> > Nowadays, almost all major programming frameworks support calendar
> > globalization. We are a small group of developers working with
> > non-Gregorian calendars and we believe Qt must support this too. This
> > proposal discusses details of our plan (and early implementation) to
> > add support for multiple calendar systems in Qt library.
> Excellent initiative. I've only had time for a cursory review (I'm
> running away for mid-winter after today, not back until January, and
> have a few other irons in the fire to get into a sensible state before I
> go) so shall have to read in greater depth next year. However, one
> thing did cross my mind in reading:
> How about having the QCalendarSystem object be an optional parameter to
> various methods of QDate, that configures how it behaves, with the
> default behaviour being that of the Gregorian system ? This has the
> advantage that client code might be able to supply a custom
> QCalendarSystem object, where an enum-based solution can only know about
> the ones that the Qt project has chosen to support.
That's interesting. Please tell me more about your idea when you're back. I
suppose adding new calendars by users, requires subclassing QDate? Or maybe
somehow extend the enum that contains calendar systems[?]. I think adding
the information on which calendar system is current date is on, can be
added as a member (handlre/enum) to QDate.
> Presumably every calendar system can be referred back to the Julian date
> , so most of the QCalendarSystem API would just implement methods
> mapping Julian date to the chosen calendar's year, month, day &c.
>  which, lest anyone be confused, has nothing to do with the Julian
> calendar - which *is* still in use ...
That's correct for Persian, Islamic and Hebrew calendar AFAIK. There math
behind is a more complex compared to Gregorian, but it will do it. I'm
learning about other calendar systems, and it seems there will be no
problem with having ant reference day as a date start point, for any
> For the sake of anyone who hasn't understood why calendar system isn't
> related to locale (or time-zone, or anything else particularly), note
> that members of a culture that traditionally uses another calendar may
> want to deal with a government-imposed (probably Gregorian) calendar
> for all their work planning while using their culture's traditional
> calendar when organising family and community events. A conference
> centre organiser, furthermore, may want to be able to switch freely
> between calendars to get a view of their diverse guests' perspectives in
> order to avoid cultural gaffes and be ready to accommodate
> complications. Even if there's nothing religious about the conference,
> knowing that it happens to fall in Ramadan will prime the conference
> centre staff to be ready to accommodate any attendees who won't be
> eating during the hours of daylight,
Exactly! Locale, Time Zone and Calendars can be used in any combination. We
may want to have date and time in Persian calendar, written in German, on
on CET +01:00 to celebrate Nowrooz in Berlin. And we must be able to have
multiple calendars in one application.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development