Ok, now I'm confused.
What are we trying to represent here? Because I assure you no matter what you
think you are wrong. If you're using a standard calendar for astronomy (to
obtain orbital position and tilt), you'll be wrong because a "sidereal year" is
not equal to a "tropical" year and so forth (same thing for days). For the
Gregorian calendar, we're stuck with a piece-wise function because they've
inserted months (_Oct_ober is 10th month?) etc. I always liked the Unix epoch,
because that was a Monday on Jan 1, which is very convenient for 99% of the use
cases of calculating a date relevant to modern, everyday life. It also gives a
good duration and won't rollover until 2038, when everything will be equipped
with 64-bit computing. Going forward from the Unix epoch, we don't have any
leap revisions more complicated than the 4-year leap day rule.
Anyway, is we need some obscure calendar, I believe the Mayan calendar is the
best since that ends in just over a year, and is more precise than all other
calendars to my knowledge.
________________________________
From: Thiago Macieira <[email protected]>
To: [email protected]
Sent: Monday, August 22, 2011 4:13 AM
Subject: Re: [Qt5-feedback] QDateTime in Qt5: First code
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.
> 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.
> 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.
> 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.
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).
> 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.
> 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.
> 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?
> > 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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
