On Friday 19 Aug 2011 23:45:54 Thiago Macieira wrote:
> On Friday, 19 de August de 2011 16:55:44 John Layt wrote:
> How many ways are there to represent a Julian day? And do we need anything
> else other than julian days to represent days?
>
> The only problem with QDate in Qt 4 was the range. We're fixing it now.
>
> I don't want to pay the price for the indirection for the next 3-6 years
> because of that. We can keep QDate and QTime without private classes.
If the date is a container and the calendar is not embedded then yes, there's
no need for the private and the inlines can stay.
> 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
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.
> 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.
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.
In which case, why do we have both isNull() and isValid() if they are just the
inverse of each other?
> 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.
> 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?
> 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.
> The calendar is a visual representation, not the invariant. The date is the
> same everywhere, it's just the implementation that changes.
Mostly visual, but it's also a mathmatical manipulation, e.g. adding 1 month
varies depending on the calendar, which month you're in and where in the month
you are.
> > So in most cases devs will have to remember to do:
> > QLocale::system().toString(myDate);
> >
> > rather than using the current and more obvious:
> > myDate.toString();
>
> Yes. I don't think it's a problem if the latter never shows a localised
> date: you'll very quickly realise it's not what you want.
>
> More so if we only include generic date representations like ISO
> formatting, not a human representation.
> > so every date
> > formatting operation would need to be changed when porting to Qt5.
>
> That's a valid argument. We can add QT4_COMPAT support methods for those.
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
> > we currently don't have toString(QDate) methods in QLocale
Doh, dunno why I said that, especially as I had just been looking at the
QLocale formatting code comparing it to the very different QDate formatting
code implementation trying to figure out which one to use in the new
QDateTimeFormatter class.
> 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.
So as I understand it, here's what you want to happen:
1) QDate stays as it is except:
* Uses qint64
* Uses Gregorian not hybrid
* Wraps current toString() and fromString() with QT4_COMPAT
* Add toString() and fromString() methods for simple formats
2) QCalendarSystem
* New virtual base class, api takes QDate like current KDE code does. Make
abstract?
* Derive implementations from this (e.g. QCalendarSystemGregorian), are
derived classes made public? Probably yes, or provide factory method?
* Does Qt have a macro like KDE's RESERVE_VIRTUAL_n I can use for BC
safety?
3) QLocale
* The new CLDR based name and format api seems acceptable?
* The toString / fromString methods get changed to the new CLDR api
* Do I have to keep the old api as well inside QT4_COMPAT? I'd rather not.
* Add calendar() method to access locale default calendar object
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);
Do we do a QLocalDate (derived form QDate?) that is a convenience wrapper
around all three, or leave that for KLocalDate?
> > > An interesting question for TZ support: suppose you have a timezone
> > > definition that points to a file that isn't in /usr/share/zoneinfo.
> > > This file can change. When is this file reloaded, if at all?
> >
> > Interesting indeed and I have no answer (yet), I'll see how KDE deals
> > with it.
>
> KDE has a module in kded. That's unacceptable for Qt.
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.
> 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.
John.
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
