58fd829cdf
The actual formatting of date-time strings is handled by the calendar backend, but the code's in qlocale.cpp as it uses some of its tools. When feature timezone is unavailable, we're stuck (as before) with using QDateTime::timeZoneAbbreviation(), but when it's available we can use QTimeZone::displayName() to get the localized form of the abbreviation and offset string. Make matching changes in QDTP so that it recognizes these localized abbreviations. We now have another candidate for what local time might be called, to add to those that must be checked. This naturally implied some changes to tests. It turns out ICU believes en_US uses GMT+1/GMT+2 for CET/CEST. Replace some MS QEXPECT_FAIL()s by including the non-abbreviations we do in fact use on MS in the lists of "abbreviations" to accept. [ChangeLog][QtCore][QLocale] When a datetime format includes the timezone (or offset), the appropriately localised form is (to the extent the timezone backend in use supports this) used where, previously, a haphazard choice of system and C locale was used. This applies to both serialization and parsing. Task-number: QTBUG-115158 Change-Id: I04f9c1055c3b9008320bb8b758490287fd8be5cd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||
---|---|---|
.. | ||
qanystringview | ||
qbytearray | ||
qbytearray_large | ||
qbytearrayapisymmetry | ||
qbytearraylist | ||
qbytearraymatcher | ||
qbytearrayview | ||
qbytedatabuffer | ||
qchar | ||
qcollator | ||
qlatin1stringmatcher | ||
qlatin1stringview | ||
qlocale | ||
qregularexpression | ||
qstring | ||
qstring_no_cast_from_bytearray | ||
qstringapisymmetry | ||
qstringbuilder | ||
qstringconverter | ||
qstringiterator | ||
qstringlist | ||
qstringmatcher | ||
qstringtokenizer | ||
qstringview | ||
qtextboundaryfinder | ||
qunicodetools | ||
shared | ||
CMakeLists.txt |