summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Separate out the time, zone, date code from corelib/tools/Edward Welbourne2019-06-061-3486/+0
| | | | | | | | | | We'll be adding calendar code here as well, and tools/ was getting rather crowded, so it looks like time to move out a reasonably coherent sub-bundle of it all. Change-Id: I7e8030f38c31aa307f519dd918a43fc44baa6aa1 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Tidy up in tst_QDateTimeEdward Welbourne2019-05-221-8/+7
| | | | | | | | Use QCOMPARE rather than QVERIFY an equality; ditch a stray blank line. Change-Id: Ie828837919fb9d3cc774d82d0eebcf7728fed645 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Purge use of some deprecated methods from QDateTime testsEdward Welbourne2019-04-231-7/+12
| | | | | | | | | | | | | | QDateTime's short names setUtcOffset() and utcOffset() have been deprecated since 5.2, in favor of setOffsetFromUtc() and offsetFromUtc(). QDate's shortDayName() and shortMOnthName() have been deprecated since 5.10, in favor of QLocale's dayName() and monthName(). Also, the tests that were using them are testing methods only present when the datestring feature is enabled; so condition them on that feature. Change-Id: Ibfd4b132523ca8fbc1cb163353a44e0500877fd5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-02-121-0/+13
|\ | | | | | | Change-Id: Iad53d4f21263718b8ecf15fd2d1170d24c7b675d
| * Avoid read-outside-array error by QStringRef over-reachEdward Welbourne2019-02-081-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Constructing a QStringRef directly from the string, offset and a length is UB if the offset + length exceeds the string's length. Thanks to Robert Loehning and libFuzzer for finding this. QString::midRef (as correctly used in both changed uses of QStringRef, since 432d3b69629) takes care of that for us. Changed one UB case and a matching but correct case, for consistency. In the process, deduplicate a QStringList look-up. Added tests to exercise the code (but the one that exercises the formerly UB case doesn't crash before the fix, so isn't very useful; the invalid read is only outside the array it's scanning, not outside allocated memory). Change-Id: I7051bbbc0267dd7ec0a8f75eee2034d0b7eb75a2 Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Avoid races on TZ in environment via tzset() callsEdward Welbourne2018-10-221-33/+7
|/ | | | | | | | | | | | | | | | | | | POSIX specifies that tzset() consults environment variable TZ and modifies some globals; it also specifies mktime(), localtime() and strftime() to behave as if they called tzset(). Fortunately, we only call strftime() from a test and only call localtime() when not threaded. Provide wrappers for tzset() and mktime() that share the lock used by our environment-access code, to prevent races on the environment (and tzset()'s globals) when we call them. In the process, re-use tst_QDateTime's TimeZoneRollback in its older test systemTimeZoneChange() and presume that this can now be tested cross-platform, since TimeZoneRollback is used in another test where this works. Fixes: QTBUG-71030 Change-Id: I79f559b8857ea2803e73501008bf0d7158c6731f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTimeParser: avoid using an invalid hour by defaultEdward Welbourne2018-10-021-0/+8
| | | | | | | | | | | | When a time-zone does a spring-forward, skipping an hour (either to start DST or to move its standard time), there's an hour that doesn't exist on the day in question. That hour can be the first hour of the day, in which case using 0:0 as the default time is broken. So catch this case and use the first time that day that makes sense. Fixes: QTBUG-70823 Change-Id: I23dae9320a3cdd2c988841a7db1b111edb945730 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix a mis-use of QSKIP() to use qDebug() insteadEdward Welbourne2018-07-041-1/+4
| | | | | | | | | QSKIP() discards the whole test it appears in; so is not the right way to announce that (and why) the test has just skipped a few sub-tests. This was concealing a later failure on macOS, here fixed. Change-Id: I9b07208413b9e101569a22505ad41f07ade4062b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Kludge round Android's ignorance of some esoteric time-zone transitionsEdward Welbourne2018-06-261-3/+9
| | | | | | | | | | Skip a few tests that Android's time-zone information doesn't suffice to get right. Task-number: QTBUG-68835 Change-Id: Ibf8d213c96b29d74fc478a0ede686ae52b5200fb Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Cope if mktime() deems times in a spring forward gap to be invalidEdward Welbourne2018-06-211-27/+35
| | | | | | | | | | | | | | | | In tst_QDateTime::springForward(), we test correct handling of times in the gap; these are formally invalid and a mktime() implementation may reasonably reject them causing our date-time code to produce an invalid result. So handle that case gracefully in the tests, only insisting on consistency between the two ways of preparing the date. In one test, package the repeated code I was going to adapt into a macro to save repeitition. Task-number: QTBUG-68832 Task-number: QTBUG-68839 Change-Id: Ib8a16ff007f4e75ab2ccff05b1ccf00a45e50dc8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add Android to exceptions in tst_QDateTime::toString_textDate_extra()Edward Welbourne2018-06-211-4/+8
| | | | | | | | | | | Android doesn't use the proper zone-abbreviation, so just check it starts with the right date-time. Revised the way the #if-ery for that is handled, to avoid repetition of the (now more complex) condition in the two tests affected. Task-number: QTBUG-68833 Change-Id: Iceb5469f46c69ba5cdbaf7ca050ad70f2bb74f44 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Cope with Android's lack of time-zone abbreviationsEdward Welbourne2018-06-211-4/+12
| | | | | | | | | | Have a test expect what it does produce rather than fail what we can't fix. Task-number: QTBUG-68837 Change-Id: Icda7bd9968682daf97d46d597f8bb0433560cde2 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make some QEXPECT_FAIL()s consistent in form and contentEdward Welbourne2018-06-211-6/+6
| | | | | | | | They used different messages for the same excuse, which weren't well worded in any case; and their #if-ery was differently decorated. Change-Id: I28f5032693aff1036cb086ac4032c669110a5cb5 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Revise dates of Pacific/Kiritimati's day-skip transitionEdward Welbourne2018-04-061-2/+2
| | | | | | | | | | | | | The TZ database has recently revised its ccount of when they skipped a day to cross the international date line, from skipping Jan 1st 1995 to skipping December 31st 1994. So Move the before-days check to December 30th; and correct the Feb 2nd that was meant to be Jan 2nd (and does need to remain so, for compatibility with systems with out of date data). Task-number: QTBUG-67497 Change-Id: I5b9483c553205817f995f91793662a5a85e03192 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Merge remote-tracking branch 'origin/5.9' into 5.11Liang Qi2018-02-141-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/corelib/animation/qvariantanimation.cpp src/corelib/global/qglobal.cpp src/corelib/global/qlogging.cpp src/corelib/io/qprocess_win.cpp src/corelib/json/qjsonarray.cpp src/corelib/tools/qsimd_p.h src/corelib/tools/qtimezoneprivate_p.h src/corelib/xml/qxmlstream_p.h src/gui/kernel/qsimpledrag.cpp src/gui/kernel/qsimpledrag_p.h src/plugins/generic/generic.pro src/plugins/platforms/cocoa/qcocoamenu.mm src/widgets/styles/qmacstyle_mac.mm tests/auto/concurrent/qtconcurrentmap/BLACKLIST tests/auto/corelib/io/qfileinfo/tst_qfileinfo.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/gui/kernel/qwindow/BLACKLIST tests/auto/widgets/dialogs/qmessagebox/BLACKLIST Change-Id: I508d686cf20f7f8cc6a7119b9bc7c3bbb505c58e
| * Clean-up in QDateTime's parsing of ISODate{,WithMs}Edward Welbourne2018-02-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually check that there's a T where ISO 8601 wants it (instead of just skipping over whatever's there), with something after it; move some declarations later; add some comments; and use the QStringRef API more cleanly (so that it's easier to see what's going on). Simplify a loop condition to avoid the need for a post-loop fix-up. This incidentally prevents an assertion failure (which brought the mess to my attention) parsing a short string as an ISO date-time; if there's a T with nothing after it, we won't try to read at index -1 in the following text. (The actual fail seen had a Z where the T should have been, with nothing after it.) Add tests for invalid ISOdate cases that triggered the assertion. Task-number: QTBUG-66076 Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd Reviewed-by: Israel Lins Albuquerque <israelins85@yahoo.com.br> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit a9c111ed8c30a5a8fec3f02244f0d5a4bd08e931)
* | Merge remote-tracking branch 'origin/5.10' into devLiang Qi2018-01-201-5/+7
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: If089d5010d15c33b3c1f13912d4386207456c1a9
| * | Skip a date-time test when we don't know what result it should giveEdward Welbourne2018-01-121-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The operator_eqeq(data13) test expected the local-time epoch and UTC epoch to agree precisely if the localTimeType set by the test's constructor says local time is UTC; however, when the local zone is *sometimes* ahead of (or behind) UTC, due to DST, localTimeType is duly set to indicate that, which doesn't preclude the zone agreeing with UTC at the epoch. This indeed happens for Europe/London, which agrees on the epoch but was ahead a few months later. So we can't determine what outcome to expect based solely on localTimeType, although we can be sure of a match when local time is UTC. So skip this test when local time isn't UTC (and document what's going on a bit better). Task-number: QTBUG-65435 Change-Id: Id9b8aa0402f2a2b410e0234f6eca4ab0d1010bc4 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Merge remote-tracking branch 'origin/5.10' into devLars Knoll2018-01-021-2/+2
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf sc/corelib/io/qfsfileengine_p.h src/corelib/io/qstorageinfo_unix.cpp src/platformsupport/eglconvenience/qeglpbuffer_p.h src/platformsupport/input/libinput/qlibinputkeyboard.cpp src/platformsupport/input/libinput/qlibinputpointer.cpp src/plugins/platforms/cocoa/qcocoamenu.mm src/plugins/platforms/ios/qiosscreen.h src/plugins/platforms/ios/qioswindow.h src/plugins/platforms/ios/quiview.mm src/printsupport/dialogs/qpagesetupdialog_unix_p.h src/printsupport/dialogs/qprintpreviewdialog.cpp src/printsupport/widgets/qcupsjobwidget_p.h src/widgets/widgets/qmenu.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Iecb4883122efe97ef0ed850271e6c51bab568e9c
| * | Special-case parsing of Zulu time-zone in date-timesEdward Welbourne2017-11-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsing a date-time's zone, a stray Z denotes UTC (a.k.a. Zulu time), despite not being a valid name for the zone. Clients parsing such date strings had to treat the Z as a literal, rather than a zone-ID, but then they got back a LocalTime instead of the UTC the string actually described. So teach QTimeZoneParser to handle this special case and adapt an existing test (that used a time ending in Z, but had to treat it as a local time) to check this works. [ChangeLog][QtCore][QDateTime] When parsing a time-zone, "Z" is now recognized as an alias for UTC. Change-Id: Ib6aa2d8ea2dc6b2da526b39aec74dbc007f90fd8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Raise the upper bound on years to 9999Edward Welbourne2017-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test-case taken from bug-report; fits in as an easy row in an existing data-driven test. Add similar tests for date-time and time; and an isValid test on the end of year 9999. The date-time parser was using the end of year 7999 as maximum value for dates and date-times; extend this to year 9999, as I can see no reason not to. [ChangeLog][QtCore][QDateTime] Years up to 9999 can now be parsed without error (previously 8000 and beyond were treated as invalid) in all formats (not only in ISO format). Widgets handling dates now support dates to 9999, likewise. Task-number: QTBUG-64401 Change-Id: I518cfa6c2cb4ecc5a85b896dc9e56b4fdd8a8bb1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Remove references to obsolete platformsJake Petroules2017-11-051-21/+0
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | ultrix and reliant have not seen a release since 1995. dgux not since 2001. bsdi not since 2003. irix not since 2006. osf not since 2010. dynix... unclear, but no later than 2002. symbian needs no mention. All considered obsolete, all gone. sco and unixware are effectively obsolete. Remove them until someone expresses a real need. Change-Id: Ia3d9d370016adce9213ae5ad0ef965ef8de2a3ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Clean-up in QDateTime's parsing of ISODate{,WithMs}Edward Welbourne2017-08-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Actually check that there's a T where ISO 8601 wants it (instead of just skipping over whatever's there), with something after it; move some declarations later; add some comments; and use the QStringRef API more cleanly (so that it's easier to see what's going on). Simplify a loop condition to avoid the need for a post-loop fix-up. This incidentally prevents an assertion failure (which brought the mess to my attention) parsing a short string as an ISO date-time; if there's a T with nothing after it, we won't try to read at index -1 in the following text. (The actual fail seen had a Z where the T should have been, with nothing after it.) Add tests for invalid ISOdate cases that triggered the assertion. Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd Reviewed-by: Israel Lins Albuquerque <israelins85@yahoo.com.br> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Add a date-time test for time-zones near epoch and odd transitionsEdward Welbourne2017-07-311-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | Check we do handle DST after epoch and don't before. Check we do notice various unusual transitions. Check we do handle non-whole-hour-offset zones. (Unfortunately, MS-Win lacks data for some of the zones and is wrong about the two date-line crossers, so we skip those for it.) Change-Id: If420d61b9db7f914ca25c22297c16e917ad2307a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | tst_QDateTime::toTimeSpec(): verify round-tripping works cleanlyEdward Welbourne2017-07-071-0/+4
| | | | | | | | | | Change-Id: I811fa4249dae923e5e4e434910d8bf96c15bff25 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Clarify tst_QDateTime::fromStringToStringLocale() using a macroEdward Welbourne2017-07-071-7/+9
| | | | | | | | | | | | | | | | | | | | | | Separate the part varying between tests from the common form of all the tests, so the reader can see the common pattern and know for sure that there's not a typo or copy-and-paste glitch. Change-Id: I3145a26ab42c104eb27756d906ac87f937024bad Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QDateTimeParser: implement parsing of time-zone specifiersEdward Welbourne2017-06-201-4/+0
|/ | | | | | | | | | | | | | | | | The serialization of date-times understood time-zones (indicated by a 't' in a format string) but the parsing didn't (so viewed the 't' as a literal element in the format string, not matched by the actual zone it needs to parse), although some tests expected it to. This made round-trip testing fail. Implemented parsing of time-zones. Re-enabled the formerly failing tests. [ChangeLog][QtCore][QDateTime] Added support for parsing of time-zones. Task-number: QTBUG-22833 Change-Id: Iddba7dca14cf9399587078d4cea19f9b95a65cf7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-03-131-0/+73
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/network/network.pro mkspecs/features/mac/default_post.prf src/corelib/io/qfilesystemengine_win.cpp src/corelib/io/qprocess.cpp src/corelib/io/qprocess.h src/corelib/io/qprocess_p.h src/corelib/io/qprocess_unix.cpp src/corelib/io/qprocess_win.cpp src/corelib/thread/qmutex.cpp src/platformsupport/fontdatabases/windows/windows.pri src/plugins/platforms/eglfs/eglfsdeviceintegration.pro tests/auto/corelib/io/io.pro Change-Id: I8a27e0e141454818bba9c433200a4e84a88d147e
| * Fix parsing of day-of-week names that start with another nameThiago Macieira2017-02-281-0/+50
| | | | | | | | | | | | Task-number: QTBUG-59159 Change-Id: I95c9e502ccc74af3bcf0fffd14a69e0cd27ce96b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
| * QDateTime: Fix clearing the ShortData flag in setMSecsSinceEpochThiago Macieira2017-02-241-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike setTimeSpec, this forgot to clear the bit when detaching. So it's possible that some further use of the flags could incorrectly conclude that the data was short and then proceed to corrupt the pointer. The example from QTBUG-59061 caused this because toUTC() -> toTimeSpec() calls setMSecsSinceEpoch which left the bit set; then addDays() calls setDateTime(), which calls checkValidDateTime() and that corrupted the pointer. This problem was more visible on 32-bit systems because no QDateTime was short (except for default constructed ones), but it can happen on 64-bit with sufficiently large dates. Task-number: QTBUG-59061 Change-Id: Ibc5c715fda334a75bd2efffd14a562a375a4e69b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-02-241-13/+15
|\| | | | | | | | | | | | | Conflicts: mkspecs/features/moc.prf Change-Id: Ia71c8e3b3185f7c999bf226d0675051b10b8740b
| * Make sure to use C locale during time tests that assume itEdward Welbourne2017-02-201-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some format and parse tests for time and date-time depended on locale but had test data for the C locale (so fail if the test-environment has, e.g., LANG=de_DE@utf8). So impose the C locale (until Qt 6). The date-time test did *some* attempts at fixing for locale, but failed to handle am/pm; and we do have "### Qt 6" comments in Q(Date|Time)+::fromString indicating that we intend to switch these methods to use the C locale by default (which shall fix this once and for all). So rip out the incomplete localization now and test we work properly at least when the locale used *is* C. Add a comment to the matching QDate test to rip out its (presently adequate) matching code once we do get to Qt 6 and make fromString() use the C locale. QDateTimeParser uses systemLocale(), which is initialized the first time it gets accessed; so we need to frob the locale *early*; doing so in the test-class constructor is about as early as we conveniently can; and seems to work (while doing it in individual tests does not). (There is no point rolling back at the end; the QSystemLocale global has been set up by then, so the roll-back would merely leave the global out of sync with setlocale() and the environment.) Task-number: QTBUG-58728 Change-Id: Ifa6778a80276050a099387a6dab15a1096be7561 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* | Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-02-161-13/+25
|\| | | | | | | | | | | | | | | | | Conflicts: src/corelib/plugin/qlibrary_unix.cpp src/plugins/platforms/xcb/qxcbconnection.cpp tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp Change-Id: I632c400d909f8c204f55743aadc7886af2f15dfb
| * Package transient zone setting in test to ensure restore on failEdward Welbourne2017-02-151-13/+25
| | | | | | | | | | | | | | | | | | | | | | tst_QDateTime::operator_insert_extract() was setting the time-zone and taking care to restore it at the end of the test; however, if the test were to fail, the restore would be skipped. Package the zone-setting and restore in a class instance, so that premature return can't bypass the restore. Change-Id: I3df63260da17e481ef4d0d107d9f0fdea3e147e7 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* | Remove two unused static methods of QDateTimePrivateEdward Welbourne2017-01-121-2/+0
| | | | | | | | | | | | | | ... along with the two matching unused methods of QDateTime's test. Change-Id: Id11a4b1b0132587f0df451d49c0043e9425d87ad Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QDateTime test: clarify overflow-checkEdward Welbourne2017-01-021-6/+4
| | | | | | | | | | | | | | | | | | | | | | An overflow-check needed the datum for the "min" test to be minus the datum for the "max" test; so explicitly make the former use -max() instead of synthesising it as min()+1. This simplifies the explanation of why that's needed, too. Clarify the overflow-check's comment at the same time. Change-Id: I41f56764fdf5e8c749bfae7a685e5fb77d37b3a8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Fix handling of time-zones in QDateTime::toString(Qt::TextDate)Edward Welbourne2016-12-141-0/+44
| | | | | | | | | | | | | | | | | | | | | | Previously, a zone-based time would claim to be GMT, rather than identifying its zone properly. Sadly, testing this reveals that proprietary operating systems don't handle abbreviations ideally. Task-number: QTBUG-57320 Task-number: QTBUG-57298 Change-Id: I8d8b7fffdbf65ac6178a65f5fc2df4d25afb1a14 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Fix QDateTime::toString(Qt::ISODate)'s handling of Qt::TimeZoneEdward Welbourne2016-12-141-0/+23
| | | | | | | | | | | | | | | | | | | | When the time is specified relative to a zone, the ISO date produced lacked its offset suffix; all zones were treated as if they were local time. Handle zone as for an offset from UTC and ensure we do set the date-time objects's offset from UTC when it's zone-based. Change-Id: I7c9896bb8ec0a9d89df14a6e94b005174ab9e943 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QDateTime, QTimeZone: fix mappings from zone time to UTCEdward Welbourne2016-12-121-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Such mappings are ill-defined in the presence of daylight-savings time (DST); at its transitions, you need information about whether DST is active or not to determine the correct UTC value. Existing code did not have a way to be told that hint, so could not be correct. Fixing this required changing the (thankfully private) APIs by which QDateTime accessed QTimeZone's information stipulated by zone time. In QDateTime, this required propagating the needed hint, when DST status was known. QAndroidTimeZonePrivate overloaded QTimeZonePrivate::dataForLocalTime with an implementation that works whenever !hasTransitions(); the base implementation handled this case lamely, so I've moved the Android implementation there, to have only one place for both re-writes. Amended tst_QDateTime's expected failures; passing a date and time to the constructor *is* ambiguous when the moment indicated is in a transition. I have changed which way we resolve that ambiguity. Added round-trip test of QDateTime's fromMSecs/toMSecs (but as a QTimeZone test, since that's what's actually getting tested), based on a test-case from Marko Kangas. Initially failed for various zones, each at one hour-offset; and, on some platforms, for some zones, at all offsets. These last revealed that a platform may claim to have zone information yet, for some zones, lack it (or have very incomplete information). In each case, despite this, the platform does give offsetFromUtc(). (The test also found another pre-existing bug on Linux; fixed in an earlier commit.) To accommodate these gaps in transition data, the transition-based code now falls back to the offsetFromUtc()-based code (used when there are no transitions) if it can't find a previous transition (which, in any case, it needs to do its job). Task-number: QTBUG-56460 Task-number: QTBUG-56397 Task-number: QTBUG-52284 Change-Id: I2f7422a9e9d3767940b1901d887c6a2c1f36ac9f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add Qt::ISODateWithMs date format, with support in QTime/Date/DateTimeTor Arne Vestbø2016-10-201-8/+18
| | | | | | | | | | The Qt::ISODate format strips milliseconds, so a new format is introduced that keeps the milliseconds. A new format was chosen over fixing the existing format due to the behavioral change of suddenly having ms as part of Qt::ISODate. Change-Id: If8b852daed068cce8eee9b61a7cd4576bc763443 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDateTime: introduce {to,from,set,current}SecsSinceEpochThiago Macieira2016-06-221-65/+69
| | | | | | | | | | | | | | | | | | | | | | | | These new functions use a 64-bit integer in the API, instead of the broken 32-bit unsigned integer that the previous xxxTime_t functions used. That was a design flaw when the API was introduced back in Qt 4.2, so I'm deprecating the API and slating it for removal in 6.0. The changes to qfilesystemmetadata_p.h and quuid.cpp are necessary to build the bootstrap library. The rest of the adaptation to the new API will come in the next commit. [ChangeLog][QtCore][QDateTime] Introduced toSecsSinceEpoch, fromSecsSinceEpoch and setSecsSinceEpoch functions, which use 64-bit integers to represent the number of seconds. [ChangeLog][QtCore][QDateTime] The toTime_t, fromTime_t and setTime_t functions are deprecated and will be removed in Qt 6.0. For new code, use the equivalent functions with "SecsSinceEpoch" in the name, or the equivalent ones with millisecond accurancy that have existed since Qt 4.7. Change-Id: Ib57b52598e2f452985e9fffd145a355d0e7ff48d Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QtCore: Remove Windows CE.Friedemann Kleint2016-03-301-28/+4
| | | | | | | | | Remove QSysInfo::WV_CE_5/6 enumeration values, #ifdef sections for Q_OS_WINCE and wince .pro file clauses in library, examples and tests. Task-number: QTBUG-51673 Change-Id: Ib63463445f3a26e04d018b193e4655030002f5f9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-02-291-2/+0
|\ | | | | | | | | | | | | Conflicts: tests/auto/corelib/io/qprocess/tst_qprocess.cpp Change-Id: Ib6955eb874b516b185b45d6c38cec646fbaa95f4
| * Remove a mis-placed QSKIP().Edward Welbourne2016-02-261-2/+0
| | | | | | | | | | | | | | | | It made us skip the rest of the test, not just the small set of sub-tests that were conditioned by the if () in whose else it sat. Change-Id: I5e914e0aeb9d5ba44b21966d071aaccbc590365d Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-02-021-3/+67
|\| | | | | | | | | | | | | | | | | Conflicts: config.tests/unix/compile.test src/plugins/platforms/cocoa/qcocoahelpers.mm src/tools/qlalr/cppgenerator.cpp Change-Id: I0103ca076a9aca7118b2fd99f0fdaf81055998c3
| * Don't let a good day cause date-time parser to forget a conflict.Edward Welbourne2016-01-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Setting conflicts to isSet & DaySection cleared it if we hadn't seen the day stipulated, even if there had been a conflict (e.g. over year) before we hit the day-of-week that didn't match the (unset, so defaulting to) 1st of the month. Explicitly test for conflict and only set conflicts (to true) if there is a conflict. Added regression test. Change-Id: I7363eb66a8bb808d341738d14969039834f50db8 Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
| * Add DST-change test for a date derived via .toLocalTime().Edward Welbourne2016-01-261-0/+24
| | | | | | | | | | | | | | | | | | Uses a time derived via .toUTC() to ensure the .toLocalTime() comes out at the time we expect. Task-number: QTBUG-49008 Change-Id: I2005127929c7eab1b7a3cbaba8d21df8c9585d17 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Test .addDays() and .addMonths() are sensible around DST changes.Edward Welbourne2016-01-261-2/+40
| | | | | | | | | | | | Task-number: QTBUG-49008 Change-Id: Ie3bf9dfeb67c96b18320e18c14b9680f03cb98e9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2016-01-261-9/+6
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/android/jar/src/org/qtproject/qt5/android/QtActivityDelegate.java src/dbus/qdbusconnection_p.h src/dbus/qdbusintegrator.cpp src/dbus/qdbusintegrator_p.h tests/auto/corelib/io/qdir/qdir.pro tests/auto/corelib/io/qiodevice/tst_qiodevice.cpp Change-Id: I3d3fd07aed015c74b1f545f1327aa73d5f365fcc
| * Autotest: make tst_QDateTime pass when LC_TIME != en_USThiago Macieira2016-01-221-9/+6
| | | | | | | | | | | | | | | | | | | | | | QDateTime::toString for Qt::TextDate unconditionally uses the system locale (because QDate::shortDayName and QDate::shortMonthName do). Setting the default QLocale has no effect. If you ask me, those two QDate methods are buggy, but they are documented that way. Change-Id: I408dcb81ba654c929f25ffff1427366b04da5a43 Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>