On Sunday, 21 de August de 2011 19:57:18 John Layt wrote: > > QDate is a payload for a julian day. The calendar should be associated, > > not > > embedded. Again, I don't want to pay the price of a feature that 0.01% of > > the developers will use. > > 60% of the worlds population is not an insignificant number, even if most of > them do run their desktop in Gregorian. If this support was just about
You're contradicting yourself.
You said most of those 60% run in Gregorian. Assuming that they do that
because of lack of choice, then let's assume that half of them would run in
Gregorian anyway. That's then 40 + 30 = 70% of the world population using
Gregorian.
Next, remember that showing calendars to the user is just one of the things
that date/time manipulation can do. There's a lot of work going on that
doesn't depend on calendars, just on the number of days, like time intervals
and also exchange of information over the Internet.
Add to that the uses of Gregorian, like calculating months and years.
I'm fairly confident when I say that 99%+ of the uses of date/time need only
the facilities provided by the Gregorian calendar and regular time
measurement.
> allowing a few devs to write widgets for prayer calendars or whatever then
> I wouldn't be pushing it into Qt. There are countries where the official
> calendar is not Gregorian, there are locales that have preferred calendars
> not Gregorian, in Windows and OSX you can configure for your locale
> calendar to not be Gregorian and have it apply to everything automatically.
> I don't want devs to have to think about supporting localized dates and
> writing special code to do so because then it won't happen. It should all
> just magically happen for them, just like it does when using .Net or Cocoa.
I'm not saying that these features shouldn't be present. I'm saying that most
uses of QDate, QTime and QDateTime don't require them, so those uses shouldn't
pay the extra price of the calendaring system.
We need to find a way to support the calendaring system and optimise for the
common case.
> > Proleptic julian days should be valid, so I don't see how there can be a
> > range.
>
> There are no formulas that cover converting the entire valid jd range into
> valid ymd forms, not even for Gregorian.
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.
> But if the calendar is just a wrapper it becomes moot anyway, as the formula
> validity becomes a matter for the calendar class not the date.
Yes.
> In which case, why do we have both isNull() and isValid() if they are just
> the inverse of each other?
Convenience. Several classes do the same. Cf. QDBusReply's isValid() ==
!isError().
> > How do devs forget to use them? To transfer over wire or to store, a
> > QDataStream should be enough or an ISO-formatted date should.
> >
> > To present to the user, a dedicated widget should be used.
>
> The Qt date widgets are not great so don't get used a lot, people roll their
> own (yes, I know, I'll fix them :-). If all you're doing is displaying a
> date string, either standalone or embedded in a sentence, most people just
> use a QLabel with toString().
>
> For example, the new layout for the Plasma calendar in KDE 4.7 was written
> just using QDate::toString() onto a QTextEdit, and that was an experienced
> dev working on existing code that already did it correctly.
Agreed, that's a fair point.
> > What am I missing?
>
> You'd be amazed at the places devs display parts of the date by directly
> calling the year()/month()/day()/dayOfYear()/etc methods rather than using
> toString() or a special widget. Or where they want to do date maths without
> using a widget. If a users system is using say the Hebrew or Islamic
> calendar and there's some code in the background doing date maths on say
> firing off an alarm every month or calculating birthdays or whatever, what
> calendar will the user expect it to use?
Again a fair point.
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.
For example, we could deprecate the gregorian methods in QDate (including the
constructor) and instead add fromGregorian() and toGregorian() functions,
maybe even gregorianYear(), gregorianMonth() and gregorianDayOfMonth() as
convenience. Then the user should be aware of the assumptions made whenever
they use Gregorian.
Paralleling those, we'd have fromCalendaringSystem() and
toCalendaringSystem(enum) if possible.
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. So maybe it's best to add them like this:
QHebrewDate toHebrewDate() const;
static QDate fromHebrewDate(QHebrewDate hc);
static QDate fromHebrewDate(int hebrewYear, int hebrewMonth, int day)
QMayanDate toMayanDate() const;
static QDate fromMayanDate(QMayanDate mc);
static QDate fromMayanDate(int baktun, int katun, int tun, int uinal,
int kin);
And these functions should be possibly implemented as inline in the header
definining the calendar functions:
inline QHebrewCalendar QDate::toHebrewDate() const
{ return QHebrewDate(*this); }
inline QDate QDate::fromHebrewDate(QHebrewDate hc)
{ return hc; } // calls QHebrewDate::operator QDate()
inline QDate QDate::fromHebrewDate(int hy, int hm, int hd)
{ return QHebrewDate(hy, hm, hd); }
Maybe the dates could derive from QDate too, to provide automatic casting.
Also note the pass-by-value in my example. It's there for two reasons:
1) you can't call the function without including the header, so you never miss
the fact that it's inline and generate an undefined reference
2) the fact that I'd like these classes to be *very* lightweight, hopefully
even trivially copyable.
> > How often does a developer need to take a date add one month of the Hebrew
> > calendar?
>
> They don't. The system should do it for them without them even knowing.
> Only if they need to send it over the wire or calculate in a particular
> calendar should they even need to think about it.
And how would the system know?
A user in Israel would record my birthday in the Gregorian calendar, not in
the Hebrew one. So there's at least one case where it's not locale-dependent.
I think this is far more likely to be context-dependent everywhere, so better
to split them all out, including the Gregorian one.
> So the QDate toString api will be more like:
>
> enum QDateTime::DateTimeFormat { IsoFormat,
> CFormat, // Monday 01 January 2000
> RfcFormat };
>
> QString QDate::toString(QDateTime::DateTimeFormat format) const;
>
> #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.
> > We need to investigate which methods we'd want to remove, how/if to
> > maintain source compatibility and how much they're used. Personally, I
> > think keeping the Gregorian is useful, as very often you get dates from
> > other sources in that calendar -- seldom in JD
>
> Well, ideally we would remove everything that uses ymd, but if you leave the
> Gregorian in there then there's little point removing anything as you'll
> need to access all the methods. Alternatively, wrap all the ymd methods in
> QT4_COMPAT and document the correct methods to use.
Yep, see above as I reached the same conclusion.
> So as I understand it, here's what you want to happen:
>
> 1) QDate stays as it is except:
> * Uses qint64
ACK
> * Uses Gregorian not hybrid
ACK
> * Wraps current toString() and fromString() with QT4_COMPAT
ACK
> * Add toString() and fromString() methods for simple formats
ACK
> 2) QCalendarSystem
> * New virtual base class, api takes QDate like current KDE code does.
> Make abstract?
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?
> * Derive implementations from this (e.g. QCalendarSystemGregorian), are
> derived classes made public? Probably yes, or provide factory method?
See above.
> * Does Qt have a macro like KDE's RESERVE_VIRTUAL_n I can use for BC
> safety?
No need if we don't have virtuals.
> 3) QLocale
> * The new CLDR based name and format api seems acceptable?
ACK. Talk to Denis here.
> * The toString / fromString methods get changed to the new CLDR api
ACK.
> * Do I have to keep the old api as well inside QT4_COMPAT? I'd rather
> not.
I'd rather you did, unless there's a very strong reason not to, as in "it's
completely broken and no one should use it".
> * Add calendar() method to access locale default calendar object
ACK. Probably "calendarSystem".
> So, a dev wanting to localise dates properly will need to do:
>
> myString = QLocale::system().toString(myDate, QLocale::ShortFormat);
> myYear = QLocale::system().calendar().year(myDate);
> myDate = QLocale::system().calendar().addYears(myDate, 1);
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.
> Do we do a QLocalDate (derived form QDate?) that is a convenience wrapper
> around all three, or leave that for KLocalDate?
Convenience is good.
> Agreed, but I meant I'll see what strategy KDE uses, not how we implement
> it. I think reading the tz file will be a platform specific function using
> whatever api the system has available. On Windows we'll query the registry
> and do conversions. On OSX we'll use whatever api they have or read the
> file directly. On Linux we'll read the file directly (glibc has functions
> for reading it but I'm told they're too simplistic for our use). On
> KDE/Linux we may be able to optionally use the kded module if it's running.
> As for how/when it gets reloaded, like I said, there's a lot of research
> for me to do.
That brings an interesting question related to the QtCore platform plugin.
> > One interesting thing: calendaring systems and locales are orthogonal.
> > Can't I have Arabic month names in Portuguese? And what database is there
> > for such a thing? Does the CLDR contain the info we need?
>
> Yes, you probably can. In CLDR each locale can define translations and
> formats for each calendar system even if not on the list of preferred
> calendars for that locale, if not defined then inherited defaults are used.
> I think Denis is also looking at how to mix different locales for groups of
> settings, i.e. have different locales used for date and number settings.
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;
--
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
