[Development] Calendar Systems proposal

[Soroush Rabiei]

>
> If you change QDate's internals, you have to wait for Qt 6.
>
> You can add to its API before then, though.
>

Hmm... I'll think of something else then.

I thought these changes are backward compatible (API only), though it seems
I'm mistaken. Maybe missing something about ABI compatibility: Adding a
member will change memory layout and eventually client apps will be forced
to recompile I suppose...


> 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.
>
>
It will support Gregorian day, month, year of course, adding calendaring
system will not change default behavior. But it will change if calendar is
set to something else. Nevertheless, it seems not possible for QDate to
change in semantics in anyway, not for Qt6 nor any release.

Following these rules, we need a new design, without changing QDate
interface nor its internals. I'm thinking of some changes in viewer widgets
and view classes to change their current calendar (utilizing calendar
classes and QLocale) without breaking compatibility.

Cheers,
Soroush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161219/bccc2338/attachment.html>