On Thu, Dec 15, 2016 at 3:53 PM, Edward Welbourne <edward.welbou...@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.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
