On 8/22/11 10:13 AM, "ext Thiago Macieira" <[email protected]> wrote:
>On Monday, 22 de August de 2011 00:13:42 John Layt wrote:
>> 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.
>
>Still, they are highly inaccurate compared to what?
>
>Remember we defined that there are 365*400 + 1*97 = 146197 days every 400
>years. When do they break down to that definition?
>
>> > > #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?
>
>The methods have to be inline. We can't repeat the mistake of having non-
>inline Qt3Support methods.
Agree with Thiago.
>
>> 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 :-).
>
>Why wouldn't we support it? I used the Mayan calendar as an example of
>something that is so radically different to provoke the thinking of
>what's
>common between calendaring systems.
>
>> 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.
>
>Okay, so there is the possibility of a common base class. Now the
>question is
>whether we need it.
>
>[snip listing of API]
>
>Interesting read. The API looks sane, including the week numbers thing.
So can we do one API for all calendaring systems? If yes, we should most
probably use that fact.
I do agree with Thiago that QDate should be really just a mathematical
representation of a Date. At maximum have some support to convert to
gregorian dates.
How about a QCalendar class that takes the System as an enum? If we can
use a common API, one class with an enum for the system sounds best to me.
Having separate classes for each calendar sounds suboptimal for some
reasons:
* I'd also like the class to be a simple value based class. That conflicts
with the concept of a virtual base class.
* A virtual base class also adds the requirement of having factory methods
to get to the right system. Not very nice in terms of usability.
* A QHebrewCalendar etc. means the app developer will hardcode the
calendar used. In many cases the app needs to be flexible because the end
user chose the calendar system, so this will not work very well.
>
>> 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.
>
>Will that also be true with CLDR?
>
>> 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.
>
>Sorry, I didn't understand. How would the era move to QLocale?
>
>> 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.
>
>What scaling is required? We've defined that we're going to support only
>CLDR
>calendars.
>
>But I get the point of code duplication.
I think the problem is that this will lead to hardcoded calendaring
systems in the apps. See above.
>
>> 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?
>
>One big switch is fine by me.
One big switch, or a private class with virtuals are both fine. I don't
know enough about how difficult each approach would be to maintain, but in
the end this is then an implementation detail we can change at any time in
the future.
>
>We need to remember to unit-test every function under every calendar
>system,
>at the very least to check that we don't hit the
> default:
> qFatal("Impossible calendaring system");
>
>at the end of the functions (need to do that anyway).
Yes.
>
>> 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).
>
>class QHebrewDate: public QDate
>{
> // optional: cached calculations
> // we could recalculate at every call to year(), month() and day()
> int yr, mnth, dy;
>public:
> QHebrewDate();
> QHebrewDate(int year, int month, int day);
> explicit QHebrewDate(const QDate &other);
> // trivial QHebrewDate(const QHebrewDate &other);
> // trivial ~QHebrewDate();
>
> int year() const { return yr; }
> int month() const { return mnth; }
> int day() const { return dy; }
> int dayOfWeek() const;
> int dayOfYear() const;
> int weekNumber() const;
> // ...
>
> // setters are non-inline
> void setYear(int year);
> // manipulators are non inline
> QHebrewDate addYears(int count) const;
> QHebrewDate addMonths(int count) const;
> QHebrewDae addDays(int count);
> friend QHebrewDate operator+(QHebrewDate d, QTimeSpan s);
> friend QHebrewDate operator+(QTimeSpan s, QHebrewDate d)
> { return d + s; }
>};
>
>There's very little code that is shared between all implementations. The
>biggest copy & paste is the actual class definition.
That's quite a bit of copy/paste. But as noted above I don't like this too
much as it would in many cases force the app developer to himself take
care of every possible calendar system (if the calendaring system is not
hardcoded for a certain use case, but chosen by the end user).
>
>> 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?
>
>That's the worst of both worlds IMO.
No. Let's keep the concept of a date and it's representation to the user
separate. We're doing the same in QString now because doing implicit
conversions to a locale/user dependent format has given us many hidden
bugs before.
>
>> 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.
>
>We could decide to use CLDR everywhere. What arguments do we have to
>using the
>Windows API for calendars? What calendars does it support? What if it
>lacks
>some API we need or some calendar we need?
Let's please not go into using platform dependent code (or integrating
with it) for the moment. Using CLDR makes all of the code 100% cross
platform and thus a lot easier to test.
>
>> > 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?).
>
>Not at that level, that's too much overhead for such a simple operation.
>
>I was mostly thinking about how to find the locale and what the user
>settings
>of date/time formatting are.
>
>> > 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);
>
>Not if we have no base class.
We need some method to provide locale dependent dates in QLocale. And that
naturally includes using the calendaring system the end user has chosen.
Another reason why a separate class per system is IMO not a good idea.
To sum it up, I'd prefer one value based QCalendar(System) class without
virtuals. It contains a Julian QDate and an enum for the system.
Cheers,
Lars
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
