On Monday 02 January 2017 09:21:25 Lars Knoll wrote:
> I wonder whether we can't keep handling of different calendars completely
> outside of QDate. Something similar to what we've done with
> QString/QLocale. So QDate would continue unchanged and only support the
> standard Gregorian calendar. In addition, we have a QCalendar class, that
> can be constructed with a different calendar system, and can then return
> 'localized' date strings, days, months and years for this calendar system.
> 
> Something like:
> 
> QDate date;
> QCalendar c(QCalendar::Hebrew);
> QString hebrewDateString = c.toString(date);
> int hebrewYear = c.year(date);
> 
> Maybe one could even integrate this into QLocale, that already provides
> support for localized month and day names?

There is more to it than converting a date to a string:

* Add N days to a date.
* Find the number of days in a month.
* Compare two dates.
* Count the number of days between two dates.

For instance a program wishing a happy new year to its users should do it with 
as little modifications as possible.

Using a plain QDate would have been the easiest way to reach more users 
because it doesn't require to replace lots of QDate with a new, very similar, 
class. As it is not possible to change QDate for now, Soroush is looking for a 
temporary solution that would bridge the gap until Qt6 is out.

BTW, happy new year to those using the Gregorian calendar :-)

Frederic

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to