On Sunday 21 Aug 2011 21:05:27 Thiago Macieira wrote:
> Huh? I think you're missing the point of "proleptic". It means "assuming
> the rules were then as they are now". So if we assume the forumlae were
> the same, at what point would they become invalid?
>
> Hint: by definition, never.
Ah, but in the real world, try using the current QDate formulas for any year
before 4800 BC or after about 1.4 million AD, the formulas break down and give
nonsense results. Many formulas have not been written to cope with negative
years, or large values, or are simplified for speed in the most commonly used
date range. Now, I do have better formulas than QDate currently has, but for
some other calendar systems it is a limitation.
> > #ifdef QT4_COMPAT
> > QString toString(Qt::DateFormat f = Qt::TextDate) const;
> > QString toString(const QString &format) const;
> > #endif
>
> Sounds good, with the note that QT4_COMPAT must be inline.
Sorry, don't quite understand that one? Do you mean I have to define the
QT4_COMPAT myself as an inline? Or the toString() methods have to be inline?
[Various key snippits...]
> With that in mind, I would say we need to make it easy to use the
> calendaring systems and make it clear to the user where they should pay
> attention.
> I'm not sure if there's a good way to implement a base class for all
> calendars, considering that they might differ greatly. And in fact I'd like
> to avoid virtuals, if possible.
> Maybe the dates could derive from QDate too, to provide automatic casting.
> 2) the fact that I'd like these classes to be *very* lightweight, hopefully
> even trivially copyable.
> NAK. I'd rather not have virtuals, if at all possible. What's common
> between the Mayan long count, the Hebrew calendar, the Islamic calendar
> and the Japanese one?
> NAK. What if the calendar has no concept of years?
>
> That's a problem I don't see the resolution for just yet. See above for the
> question on the existence of a base class or not.
Well, for a start we wouldn't be supporting the Mayan calendar, it's not
officially or even informally used anywhere and is not part of CLDR or Windows
or OSX or KDE support (much as it pains me as a budding archaeologist to say
so :-).
Amazingly, all the calendar systems supported by CLDR/Windows/OSX/KDE all use
the same Era/Year/Month/Week/Day structure and can all be supported by the
same api. I have no intention to support anything outside this standard
template. The whole point is they all work the same way so can be used
transparently by devs.
In KCalendarSystem most of the method implementations are identical, there's
just a few key calculations and variables that differ between them, the vast
majority of code is shared. Lets run through the KCalendarSystem api to see.
The following methods have different implementations for each calendar system:
julianDayToDate // currently private
dateToJulianDay // currently private
earliestValidDate // hardcoded variable
latestValidDate // hardcoded variable
isValid
isLeapYear
daysInYear // More efficient if done hardcoded, but can be derived
monthsInYear
daysInMonth
eraName // probably a QLocale/CLDR thing now
yearInEra // common code but uses ref table
hasYearZero // hardcoded variable, currently private
maxMonthsInYear // hardcoded variable, currently private
The following have different values, but are informational only:
epoch
isLunar
isLunisolar
isSolar
isProleptic
The following methods use the same code to calculate their values using the
previous methods:
setDate
getDate
year
month
day
daysInWeek // Always 7, we won't do the French Republican
dayOfYear
dayOfWeek
addYears
addMonths
addDays
dateDifference
yearsDifference
monthsDifference
daysDifference
The following are currently ISO weeks only in Qt, but KDE now supports
localized weeks such as US weeks, so these vary depending on locale rather
than calendar system:
weekNumber
weeksInYear
I haven't listed the name/format/parse methods as those will be in QLocale,
they all use the same parser/formatter code excpet the Hebrew language which
has a few special paths.
There's also some more convenience methods I haven't listed that are all
common code.
Note also that almost everything is hard-coded and accessed via methods not
variables, the only variables are for eras which would move to QLocale, so
there's nothing to copy.
So how to do that in Qt?
One thing I know I do not want is toHebrewDate() and fromIslamicDate() and
chineseDay() all over the place, it's ugly and doesn't scale, either use
derived classes or a common method name with a QLocale::CalendarSystem enum as
an argument.
If you don't want virtuals (and I can't disagree, they caused no end of issues
in KCalendarSystem) then how about a flat QCalendarSystem class that
internally just switches where it needs to based on a QLocale::CalendarSystem
variable? Or a single QCalendarSystem class with a virtual private class for
each implementation?
I quite like QHebrewDate derived from QDate with automatic casting, but how to
do that without some virtuals? It also allows people to derive their own
calendars that we choose not to support, and would cater for any extra
calendar specific methods if really needed (I know of none now, but
astronomical may need some extra variables set, if we support them).
Or just merge it all into QDate with a virtual private class that defaults to
Gregorian when created standalone, but provide static methods to create a
local date when needed?
I should also note that I'm a little uncertian about the Windows and OSX
implementations. We could use the same calendar code on all three platforms,
or on Windows and OSX we could have pass the calls on to the host api to do
the conversion calculations. While I'd normally say just use a common
implementation, the Windows calculations are known to have 'quirks' in them
that we may need to mirror so the Qt and system dates match up, and I doubt we
will have implemented all the calendars available under Windows for 5.0 so for
consistency we would need to use the Windows api for them. We would probably
still use our own parser/formatter code however.
> That brings an interesting question related to the QtCore platform plugin.
I was wondering if we should move the existing platform specific stuff like
currentDate() and currentTime() into the QtCore platform plugin (assuming
there is one?).
> But that means we need to have in QLocale:
>
> QString toString(QHebrewDate) const;
> QHebrewCalendar fromHebrewDate(const QString &) const;
> QString toString(QIslamicDate) const;
> QIslamicCalendar fromIslamicDate(const QString &) const;
No, the QLocale methods can be done with a single method using a QDate and
CalendarSystem enum argument:
QString dayName(int day,
FieldFormat format = LongName,
FieldContext context = StandaloneContext,
CalendarSystem calendar = DefaultCalendar) const;
QString toString(QDate date,
StringFormat format = LongFormat,
CalendarSystem calendar = DefaultCalendar) const;
QDate toDate(const QString &string,
StringFormat format = LongFormat
CalendarSystem calendar = DefaultCalendar);
We're just looking up a big reference table of names where CalendarSystem is
just one of the keys, then using either the locale's calendar object or the
requested calendar to do the jd<->ymd conversions.
Cheers!
John.
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
