| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Change-Id: I94420a3dfa30e4a2a4d8786621bea1dd9309bed8
Reviewed-by: MÃ¥rten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QTimeZonePrivate::isValid() just checks m_id is non-empty; so we have
to leave m_id clear if we don't get a valid time-zone back when we ask
the JNI for one. Unfortunately, JNI gives us a "valid" default zone
if it doesn't recognize the given name; so check the known names of
this zone (or of zones with its offset); if the given ianaId isn't one
of them, assume this is a bogus zone.
Task-number: QTBUG-68842
Change-Id: I6245db18c59c4261ed5fcd4d948dd773365ce61d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's nothing wrong with cloning a const QTimeZonePrivate, so make
clone() const.
Also, if you're cloning a QTzTimeZonePrivate, you already know that
you get a QTzTimeZonePrivate back. C++ supports covariant return types
for this reason, so use them.
Change-Id: I60e19e89b1b7bad080c552f1baca314ab0a6295e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The first two are the "proper" terms; the last is a colloquialism.
Also amended "daylight savings" (which summons to mind a hybrid of
"daylight robbery" and "bargain-basket savings").
Improved related wording in many of the places amended.
Task-number: QTBUG-49308
Change-Id: I726f18a344b2fe37f765a14684d1447c8b7ab00c
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 81a45e1f13fdf56129aed952a6e3479e16c14a2c replaced QSets with
QLists in QTimeZone, but forgot to adapt the Android code.
This commit fixes it.
Change-Id: I8704a39c44a9dc74147a4bb99a6f5d1bea53afa1
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android does not provide an API to access daylight time transitions,
so the standard QTimeZonePrivate::dataForLocalTime only returns
standard time without the daylight offset
Therefore provide an override,
QAndroidTimeZonePrivate::dataForLocalTime, which tests daylight time
offsets directly rather than using transitions.
Change-Id: Ia8adaf9af40da38aadfa7d22d9a3fe9da9ba24a8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
|
|
QTimeZone on a unix-based system expects IANA (Olson) timezones to be
provided in /usr/share/zoneinfo or /usr/lib/zoneinfo. But on an
Android system the timezone datafiles at this location are incomplete
(Android instead uses the java class java.util.TimeZone). QTimeZone on
Android therefore would only return the default UTC timezones, not the
full set of IANA timezones.
This patch invokes JNI on an Android system to make the full set of
java timezones known to QTimeZone.
The implementation adds a new QAndroidTimeZonePrivate class, invoked
by the private implementation of QTimeZone in place of
QTzTimeZonePrivate. QAndroidTimeZonePrivate contains adds a new
QJNIObjectPrivate [java.util.TimeZone] androidTimeZone property which
is used to access the java timezone API.
Android limitations:
1) the java class java.util.TimeZone does not provide transitions
(see http://developer.android.com/reference/java/util/TimeZone.html).
2) abbreviation( ) is provided using Java TimeZone::getDisplayName( )
with the java SHORT style. This sometimes generates a GMT reference
instead of a three-letter code, e.g. America/Sao_Paulo returns
"GMT-03:00" instead of "BRT"
3) hasDaylightTime() is handled using Java
TimeZone::useDaylightTime(), which according to java (Android)
documentation only tests for future transitions, not past transitions.
This might conflict with the Qt documentation for this function (which
is intended to test also for past transitions).
[ChangeLog][Platform Specific Changes][Android][QtCore][QTimeZone]
Android timezones are now available in QTimeZone.
Change-Id: I165a39b7d4cb30b68f2da8556d85fc5b4480da4b
Task-number: QTBUG-35908
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|