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 :-)
Development mailing list