[Development] Calendar Systems proposal

[Frédéric Marchal]

On Saturday 17 December 2016 11:16:24 Thiago Macieira wrote:
> On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote:
> > The idea is to remove all calendar
> > calculation code out of the QDate (into QCalendarSystem possibly). I think
> > QDate already has been bloated and knows more that it needs. Consequently,
> > there is no chance to add other calendaring API into QDate, and I think
> > it's wrong to add such implementation to QDate. My view of QDate is this:
> > QDate represents a day in time. So it only needs to know what day it is
> > (how many days are to the day 0).
> 
> No chance of that ever happening. QDate will continue to support Gregorian
> day, month, year, as well as ISO weeks. Support for other calendaring
> systems (or maybe even other week systems) can be provided by a different
> class, accessible from QDate and QLocale.

Can you elaborate on the reasons that prevent any change of that kind in 
QDate? Maybe they can be worked around?

Soroush's purpose is to allow the use of other calendar systems with minimum 
application changes (i.e. simply telling QDate to use a different date 
computation algorithm). I find his idea very attractive and not at odds with 
some other Qt classes.

Your solution implies developers have to know about those calendars and are 
willing to support them in their applications. That's very unlikely to happen 
if they have to change lot of code and replace QDate with another class.

As a developer, I don't want to know about the gory details of date 
computation with calendars I have never heard of. Adding "one month" to a date 
should use the same code whatever the underlying calendar is. The correct 
calendar to use should be a simple configuration parameter to make it as 
universally available as retrieving the local time irrespective of the user's 
location or generating the plural of a message in any language my application 
could be translated to even without my knowledge.

Frederic