[Interest] Question about setting QLocale

[Murphy, Sean]

> > 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