[Development] Calendar Systems proposal

[Soroush Rabiei]

On Thu, Dec 15, 2016 at 3:53 PM, Edward Welbourne <edward.welbourne at qt.io>
wrote:

> 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
> [0], so most of the QCalendarSystem API would just implement methods
> mapping Julian date to the chosen calendar's year, month, day &c.
>
> [0] 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
calendar.


> 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,
>
>         Eddy.
>

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...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161216/06a649c1/attachment.html>