> >Ok, then let's go for a QCalendar or QCalendarSystem that must be
> >initialised
> >with an enum. The constructor should default to Gregorian and there
> >should be
> >a System or Locale value to match the locale's preferred calendaring
> >system.
>
> Should the default constructor go to gregorian or should it go to
the one
> the user selected as his primary calendaring system?
Trade-off. I think it depends greatly on what Gregorian methods we
keep in
QDate for convenience. If there's enough of them to get by on trivial
operations, then QCalendar should default to the locale. Otherwise, to
Gregorian.
I'm thinking that QDate should have the getters and setters for the
year,
month and day, plus the ISO week and other ISO things, properly
marked as
such. Those functions should operate on the proleptic Gregorian
calendar even.
But the manipulation functions like addYear, addMonth, addDay, etc.
should not
be there (QT4_COMPAT only).
I'd like John's opinion here.
I hope you don't mind me pitching in at this point?
I am wondering what the plans are with those then. We use them heavily
in our QTimeSpan MR,
and as discussed at QtCS and remarked elsewhere before, I was even
planning to add some
of the date math used there to QDateTime as well (and then use that
implementation, obviously).
Would these become features of the QCalendarSystem then?
André
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
