> > The bug you want me to submit certainly
> > immediately breaks the documentation. Not necessarily a deal breaker,
> > documentation can be changed...
>
> You're right that the code and the documentation are aligned. I'm saying that
> I
> want to change the behaviour, since we did the exact same change for QString
> and QByteArray for 5.0.
Yep, I get that you want to change the behavior. I just don't agree that the
proposed behavior is better!
One spot where I differ widely from your view is that QDate/QDateTime are in
the same category as QString/QByteArray. The latter classes are designed to be
upgrades from C-style character arrays for storing bytes of data. So I view the
QString/QByteArray classes much closer to a fundamental data type than what
QDate/QDateTime represent. So I view QDate/QDateTime living at a higher level.
> Again, it depends on what you're trying to do.
>
> From my point of view of QtCore maintainer, I want QDateTime, QString and
> QByteArray to be entirely locale-agnostic
I understand what you're saying, but I'd argue that the whole concept of dates
and times is inherently locale specific, and that the general use case is that
people expect dates & times to be formatted in their local format, not
English/US. And as you've pointed out that since there are already ways to get
RFC2822Date or ISODate with existing functions, I as the developer can select
those when I know I want locale agnostic formatting for data exchange (which is
clearly what I should have done in my own application).
Also, in this discussion we've had, we've focused exclusively on the behavior
of QDate/QDateTime classes, which live in QtCore. If you make your change, what
happens with QDateEdit/QDateTimeEdit in QtGUI? Right now, unless I'm
overlooking something, QDateTimeEdit only has the following function for
setting the display format:
void QDateTimeEdit ::setDisplayFormat(const QString & format)
Which uses the same ddd, MM, etc. expressions we've previously been talking
about to set the format, it doesn't use any of the QLocale::FormatType or
Qt::DateFormat enums. If I'm on a German/Germany system and I run the following:
ui->dateTimeEdit->setDisplayFormat("dddd dd.MM.yyyy HH:mm:ss.zzz");
ui->dateTimeEdit->setDateTime(QDateTime::currentDateTime()); // widget now
shows "Dienstag 01.12.2015 10:57:48.164"
qDebug() << ui->dateTimeEdit->dateTime().toString("dddd dd.MM.yyyy
HH:mm:ss.zzz "); // where QDateTime::toString() is now using your fix,
QLocale::c()...
The debug statement would print out "Tuesday 01.12.2015 10:57:48.164". Well
this certainly seems like unexpected behavior - in both spots I used the exact
same formatting string and I got two different results... Unless you're saying
that with your fix the widget would have also said "Tuesday 01.12.2015
10:57:48.164" because QDateTimeEdit::setDateTime() would also use QLocale::c()
to populate the widget? But again that seems very weird, my locale is
German/Germany, so I'd expect to see the "dddd" portion represented as
"Dienstag", not "Tuesday". Regardless of whether it's in a widget or written
out to a file.
Sean
_______________________________________________
Interest mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/interest
