Commit Graph

5 Commits (b34158d7a1e89e5e7b32d3425c3df52aacedbb31)

Author SHA1 Message Date
Edward Welbourne b34158d7a1 Fix display-name calls in QAndroidTimeZonePrivate::init()
Following up on commits 4fa8dfee5d and
c20c7efea9, where I apparently got the
call to Java's getDisplayName() method wrong. Use the same code as our
own displayName() method used for this, pulled out as a function to be
shared by the two callers.

This requires a locale and it's not immediately obvious which to use,
so try the three most plausible candidates: C locale because IANA IDs
are typically in it; default because that's most likely what language
a user-supplied locale name might be in; and system because the name
may have come from the system, not the user.

In the process fixed some loops that didn't visit all the values they
thought they did.

Fixes: QTBUG-81975
Change-Id: I7867ca6f46951315a41c389107439acb439eaf08
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
2020-04-16 13:52:11 +02:00
Volker Krause c53cccc171 Fix JNI signature for the timezone getDisplayName call
Due to the changes in 5.14.1 this code now actually seems to be hit here,
throwing NoSuchMethodError exceptions all over the place and breaking
date/time handling quite spectacularly.

Change-Id: I9bee3de39ec98f86d7944b94e89119505f62dc6c
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
2020-03-17 08:30:32 +01:00
Edward Welbourne 78cde1bfd9 Fix mis-guided init() in default QAndroidTimeZonePrivate constructor
It set the time-zone member sensibly to the default zone, but then
called init("UTC"), which over-wrote that default with UTC.  This had
no visible effect (as the default-constructed object is only used to
access methods that (though virtual) are effectively static), but was
needlessly complicated.

Tidied up systemTimeZoneId() at the same time.

Change-Id: I897aff16855c28487a1029bef50c75ebc1ff5b55
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2019-11-27 18:27:43 +01:00
Edward Welbourne c20c7efea9 Sanitize QAndroidTimeZonePrivate::init()
It was setting the system zone ID if it somehow managed to find a
match for an empty zone name; that makes no sense.

A case-insensitive comparison seems reasonable for the "this isn't
just a default zone object, used because the name I asked for isn't
recognized" check.

It set m_id after it had checked everything, where it could just as
well have used m_id as the variable in which to record whether its
check has succeeded already.

It was using the name it was asked for, rather than the one this ended
up being mapped to, which is probably a better name to use for
it. (This should only differ in case.)

Split a long line.

Change-Id: I41a3b01ba99522ee68f3d7941c532019b9ebf946
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2019-11-27 18:27:43 +01:00
Edward Welbourne 548513a4bd Separate out the time, zone, date code from corelib/tools/
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>
2019-06-06 15:54:32 +02:00