Explicitly check that the QTimeZone is valid before trying to use it.
Change-Id: Iec415a2cb07071502fe71ee5ac92a7657e818f99
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There was a comment about the test failing for max() because of an
overflow. That happens if you're at UTC or ahead of it (to the East of
the Prime Meridian), which is how this test usually gets run (UTC,
Europe/Oslo, Europe/Helsinki, Pacific/Auckland). But if you're behind
UTC (to the West of the Prime Meridian), then the overflow happens for
min().
Change-Id: Iebba49d1303e9f18f5038f5cf23c77bf83e5fd4b
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
The private method dateForLocalTime() was not checking that transitions
were valid, resulting in infinite looping when a time zone didn't have
any future transitions.
Change-Id: I0e5d07063861778dd86056a80c36fdd9f9d36133
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
We must not include qt_windows.h in public headers,
otherwise we're cluttering the environment with a colorful
bouquet of Windows API preprocessor macros and typedefs.
Task-number: QTBUG-34058
Change-Id: I415717ea2a47f39e7f4b7ce1c1df9d49afc99278
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The RFC 2822 date format should always use en_US locale for month and
day names instead of whatever the system locale is. Also remove some
duplicate code.
Change-Id: Ia2f7ee405b4e0e2f04980301783b9488628da73f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Check if the datetime is valid before converting it to a different time
spec. If it is invalid then just change the spec to keep behavior
consistent with 5.1.
Task-number: QTBUG-34020
Change-Id: I6630ec1d50f810a2178ab3222bd32af018085f81
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Remove irrelevant test subdirs via .pro files
- Follow WinCE codepaths where applicable
- Replace unsupported Win32 APIs with WinRT equivalents
This does not aim to fix any failures in the tests themselves; it only
makes them compile.
Change-Id: Ia82bc0cc402891f8f6238d4c261ee9152b51be80
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
At the Daylight Tme to Standard Time transition, the local time repeats
itself, i.e. 2am occurs twice. Qt's behavior when setting this using
the local time is ambiguous, as it depends on the system implementation
of mktime, which behaves differently on different platforms. Currently
this behavior remains undefined. When setting using an msecs or time_t
value however we can determine the correct instance to use and cache it
to ensure that any conversion back from local time to msecs is performed
consistantly on all platforms.
Note that caching this value will result in any calculations being wrong
should the system time zone change, or its rules change. This will be
fixed in Qt 5.3 when the system time zone change signal is implemented
and QDateTime switches to using QTimeZone instead of mktime to provide
consistnt behavior across platforms.
The QTimeZone spec does not require this fix as it already caches the
correct offset in setMSecsFromEpoch().
Change-Id: I799588db474e744a6d81e80f6a0442920569ebd3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add support to QDateTime for time zones using the new QTimeZone class.
[ChangeLog][QtCore][QDateTime] Add support for a new Qt::TimeZone
spec to be used with QTimeZone to define times in a specific
time zone.
Change-Id: I21bfa52a8ba8989b55bb74e025d1f2b2b623b2a7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add new method to return if the current time is Daylight Time.
[ChangeLog][QtCore][QDateTime] Added new method isDaylightTime() to
return if the datetime is in Daylight Time or not.
Change-Id: Icb93fd5dd0b2f7d83d2d4643eeb12922c1137e3e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When Daylight Time transtion goes from Standard Time to Daylight Time
there is a "missing" hour, i.e. at 2am CET the clock goes forward to
3am. Currently QDateTime ignores this gap and considers the time to be
valid and able to be manipulated. This change respects the transition,
so any time set in the missing hour is considered invalid, and any date
maths returns valid results.
The validity in the current time zone needs to be checked every time
isValid() is called in case the system time zone has changed since the
last time it was checked. This is done by calling mktime to check the
returned result matches the expected result. This could be very
inefficient, but the returned offset value is cached each time so
mktime is not required to be called again within each method call,
effectively meaning mktime is called the same number of times by
each method. Note that this means any new methods added must be
careful to ensure either isValid() or refreshLocalTime() is called
first by any method needing to use the UTC value.
[ChangeLog][QtCore][QDateTime] The Standard Time to Daylight Time
transition for Qt::LocalTime is now handled correctly. Any date set
in the "missing" hour is now considered invalid. All date math results
that fall into the missing hour will be automatically adjusted to a
valid time in the following hour.
Change-Id: Ia652c8511b45df15f4917acf12403ec01a7f08e7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change from storing the date and time as QDate and QTime to a serialised
msecs format. This format is a direct translation of the QDate and
QTime values, it is not the actual msecs since the Unix epoch. This
msecs format ensures we are always able to recreate the original QDate
and QTime values, but should still simplify the code and improve
performance.
Because we no longer store the explicit date and time we need to store
their isNull()/isValid() status separately.
The changes in storage results in the same memory footprint as before.
Note that this change does not optimize the code nor set out to fix the
known bugs, it only seeks to maintain the current behavior, although
some bugs are fixed implicitly. More bug fixes and optimizations will
follow.
[ChangeLog][Important Behavior Changes] The supported date range in
QDateTime has been reduced to about +/- 292 million years, the range
supported by the number of msecs since the Unix epoch of 1 Jan 1970
as stored in a qint64, and as able to be used in the
setMSecsSinceEpoch() and toMSecsSinceEpoch() methods.
Change-Id: I98804d8781909555d3313a3a7080eb8e70cb46ad
Reviewed-by: Sérgio Martins <sergio.martins@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A number of QDateTime functions directly use or modify the data stored
in the private, but future changes to store msecs and status make this
maintenance more complicated. Where possible simplify this code to use
the standard msecs functions, standard constructors, or public api
instead. This greatly simplifies the functions and the following msecs
storage code changes.
This is an intermim step towards storing the time in msecs. Some
functions will be slower as a result of this change, optimization
will take place after all the msecs changes are completed.
Note this also removes a test that used valid QDates outside the range
of msecs, this change in behavior will be documented in the final
mscs change.
Change-Id: I6ef710f24babc7024091010064082e9be0b5bbfe
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test the Daylight Time transitions. QDateTime does not correctly deal
with many of these scenarios so those tests are marked as QEXPECTFAIL.
These bugs will be progressively addressed in coming commits.
Change-Id: I01eba9d6143a792f081542cb198e221efcf28e98
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Clean-up the implementation of toString() and fromString() methods in
QDate, QTime and QDateTime code to be more consistent in ISODate and
TextDate behavior, especially when handling TimeSpec.
Reformat some code so all methods are consistent in appearance and
function to make maintenance easier.
This changes some corner-case behavior in TextDate and ISODate, but
this either fixes bugs or makes the behavior match the documentation.
Change-Id: I457aa1d7cd4f448cd9f8a2e80ec635f3cb98e58c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Switch the implementation of toString() methods in QDate, QTime and
QDateTime to use the QLocale formatter, and remove the now redundant
QDateTime formatter.
Change-Id: Ie4f17c8a6e31acde3ce066f19835bb2b83351ce8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Add a new method to return the time zone abbreviation for the current
time spec. For LocalTime this is the abbreviation returned by mktime.
This new method will later be used in changes to the date formatter
and QTimeZone.
Note this change does not implement WinCE support.
[ChangeLog][QtCore][QDateTime] Add method timeZoneAbbreviation() to
return effective time zone abbreviation.
Change-Id: I265a5e96c72eb7236974f80f053f1fb341e3c816
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Add convenience methods for fromMSecsSinceEpoch() and
fromTime_t() to enable direct creation of other time specs
than LocalTime without the overhead of unncessary conversions.
For example instead of:
QDateTime dt = fromMSecsSinceEpoch(12345).toUtc();
the following saves two conversions:
QDateTime dt = fromMSecsSinceEpoch(12345, Qt:UTC);
This will improve the performance of the new QTimeZone class.
[ChangeLog][QtCore][QDateTime] Added convenience methods for
fromMSecsSinceEpoch() and fromTime_t() to take time spec to be used in
returned datetime.
Change-Id: I133635bfe3d35ee496a287257e13b2d600225a38
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
The Qt::OffsetFromUtc TimeSpec was made public in Qt 4.4 but the access
methods were never made public in the apidox effectively meaning the
feature was never used. The implementation was also incomplete and
inconsistent.
This change cleans up the implementation and exports new public API for
using the TimeSpec using new method names consistent with the new
QTimeZone support.
This change increases the QDataStream Version number for Qt 5.2 to 15.
The behavior of one constructor has changed slightly to be consistent
with the rest of the feature, but this behavior was never documented.
[ChangeLog][QtCore][QDateTime] Fully implement support for Qt::TimeSpec
of Qt::OffsetFromUTC, added new methods for offsetFromUTC(),
toTimeSpec(), and toOffsetFromUTC().
Task-number: QTBUG-26161
Task-number: QTBUG-29666
Change-Id: If3cc7fc9778ca2b831644408ae749448d5975a3a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
The unit tests were caching the original TZ value to restore later
after testing with different TZ values. The problem is reading TZ will
return a null value if no override TZ value is set, and if you then set
the TZ to null the system assumes UTC and not the system time zone.
Instead we need to unset TZ if it was null to start with.
Change-Id: Ib0625b1712e565f9fdfa99e2ffe1e5d74f059354
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime can now be converted to strings compliant to RFC 2822.
Additionally, it supports RFC 850 and RFC 1036 during parsing.
By having them all together, all type of dates found in exchanged
messages on the internet (including USENET) get supported.
Change-Id: I771066c23f409d20b31b7d802f37852ea68ca2a0
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
QDateTime.toString() is writing out milliseconds since change
15da0a5af2. Unfortunately this breaks
QDateTime::fromString() with Qt::TextDate which can't handle the new
format.
Fix by making QDateTime::fromString split up seconds and milliseconds
on a period, if any. Now
QDateTime dt = ...;
assert(QDateTime::fromString(dt.toString(), Qt::TextDate) == dt)
works again.
Change-Id: Ibfe9032e357ceaf894e33f3e33affe94f56dbf5c
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Section 4.2.2.4 of ISO 8601 allows for decimal fraction representations
of dates and times. Currently, when calling
QDateTime::toString(Qt::TextDate) or QDateTime::toString(Qt::ISODate),
the milliseconds will be omitted. However,
QDateTime::fromString(str, Qt::TextDate) and
QDateTime::fromString(str, Qt::ISODate) already support decimal
fraction representations, so this patch just adds this support to
QTime::toString, and hence QDateTime::toString().
Task-number: QTBUG-30250
Change-Id: If58e4b3d3105322c51d11a76b832e5e634d8991f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In Qt 5, I managed to break the guarantee that a deserialised local
datetime is the same time of day (potentially different UTC time),
regardless of which timezone it was serialised in. This happened after
I fixed QTBUG-4057 with If650e7960dca7b6ab44b8233410a6369c41df73a,
which serialised datetimes as UTC.
This patch reverts QDateTime serialisation to pre-Qt 5 behaviour to
restore the guarantee and consequently re-opens QTBUG-4057.
Change-Id: Iea877f7ed886f530b928067789b53534e89fe8cb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Auto tests using CET expect there to be no Daylight Time before 1980,
but Windows does apply Daylight Time. Fix expected test results to
match.
Task-number: QTBUG-30420
Change-Id: I7080598fa0a20c1cd5680782606ab983e714e546
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
It introduced a regression by requiring that a p/P was also present:
QTime time = QTime::currentTime();
qDebug() << time.toString("h:mm:ss a");
// Outputs "10:05:42 am" in Qt 4.8.
// Outputs "10:05:42 a" with 6497649730.
This patch also clarifies the QTime::toString(QString) documentation.
Change-Id: I4d73a959c2ca76304f03a4ce9717b540ad4e8811
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Currently, using QDate::maxJd() in tests will fail. This patch changes
some ints to qint64s to prevent overflows where necessary.
Change-Id: I61ebf8f233411a7544689fd5bfa9c3abee54e933
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by trying more often to get dates close enough to each other.
Change-Id: I370f7cd61bbb84fbb77ea96ff9fd82c1a6f1f76a
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
These types are either built-in or 'automatically declared' and so
don't need to be explicitly declared as metatypes.
Change-Id: I54523eb854619917123d8816d3cd6c3a1f5b4c55
Reviewed-by: David Faure <david.faure@kdab.com>
hasUnquotedAP currently only checks for an a or A, which is wrong
according to both the toString documentation and the comments for
hasUnquotedAP.
Change-Id: I03015734b846fe761085cf8f8fca2b29210cff97
Reviewed-by: Jon Severinsson <jon@severinsson.net>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
This is in line with what QTime::addMSecs and QDate::addDays do, for
example.
Change-Id: I902112486727f74f669a97bde6c42028e0838f8d
Reviewed-by: Jon Severinsson <jon@severinsson.net>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Two lines were commented out but were removed with
Ib6ceb1cb7fb4c6eca672495f96d9cfd907853c85. They have been replaced
as expected fails.
Task-number: QTBUG-22833
Change-Id: Ib154a31bffcdc8e43c6ad236df193e99334652c6
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Instead omit the whole test when Q_OS_WIN is not defined.
Change-Id: I311538ce839353d4d5e83edfd12c68968fe61215
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
addMSecs() / msecsTo() have always used qint64, and when QDate was changed
to use a 64-bit julian day, QDateTime::addDays() and QDateTime::daysTo() was
changed to use qint64 in order to support the full extended range, but
addSecs() and secsTo() seems to have been forgotten.
Change-Id: I3acc35ee2bcc9f353650eb42f97d428f706b2db6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
"The documentation states that "secsTo() does not take into account any
milliseconds", however, this is not the case. Given times 12:30:01.500
and 12:30:02.400 secsTo returns 0. If milliseconds are not taken into
account, I would expect this to return 1 (i.e. interprets the times as
12:30:01 and 12:30:02 thus truncating the milliseconds)."
Note that tests were also written for QDateTime::secsTo(), as it uses
QTime::secsTo internally. This addresses Javier's issue in the
comments of QTBUG-9304.
Task-number: QTBUG-9304
Change-Id: I9efe0c8f710db859c1d086d67ba3e5b349a56c4e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime currently serialises its private Spec enum. If a user was to
deserialise the individual components of a QDateTime separately, the
resulting timeSpec may be invalid when cast to the Qt::TimeSpec enum.
E.g.:
QDateTime dateTime(QDate(2012, 8, 14), QTime(8, 0, 0), Qt::UTC);
// ... serialise
// ... deserialise date, time, spec separately.
// spec == 2, the value of QDateTimePrivate::UTC.
// spec != UTC, will be set to LocalUnknown.
QDateTime deserialised(date, time, spec);
This patch serialises QDateTime objects in UTC and the value of
timeSpec() as opposed to QDateTimePrivate's spec. This changes the
serialisation behaviour of QDateTime for version 13 of QDataStream.
Task-number: QTBUG-4057
Change-Id: If650e7960dca7b6ab44b8233410a6369c41df73a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.
Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
In qdbus_cast(), qMetaTypeId<QDBusArgument> as well as
qvariant_cast<QDBusArgument> are used. They don't depend
on any template argument of qdbus_cast(), so their
definitions need to be available at function template
definition instead of instantiation time.
But the necessary Q_DECLARE_METATYPE(QDBusArgument)
was at the end of the header, after the defintion of
qdbus_cast(), which is too late for conformin compilers.
Fixed by moving it up just after the QDBusArgument
definition.
Similarly, in tst_qdatetime and tst_qvector, the
Q_DECLARE_METATYPE() for Qt::DateFormat and QVector<int>,
and with it the specialisation of QMetaTypeId<>, were
issued after the first use of meta typing; too late for
conforming compilers.
Change-Id: I25ca0b06e68d5184597a22708404a8f2040b2de1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
