Ref T309, found that QDateTime::fromString returns a QDateTime object with local timestamp. Using a optimized version returns UTC objects now.
- The bug was found writing a unit test for Ref T308
- Slack: https://swift-project.slack.com/archives/G7GD2UP9C/p1534848725000100
Summary:
The GFS weather data url so far was hard coded. With this commit, it is
moved into the global setup (bootstrap file).
Also the url type was changed from QUrl to CUrl, which simplified the
generation of the url including its query by using CUrl::appendQuery().
Finally it fixes sampleweatherdata, which did not have a CApplication yet.
Reviewers: #swift_pilot_client, msutcliffe
Reviewed By: #swift_pilot_client, msutcliffe
Subscribers: jenkins
Tags: #swift_pilot_client
Maniphest Tasks: T151
Differential Revision: https://dev.swift-project.org/D57
* some started with get/some not (removed get, get is normally used for our getters)
* some used swift, getSwiftXZY dir (removed swift)
* used full word "directory", not dir/directory mixed
Summary:
QCoreApplication::addLibraryPath is called before QCoreApplication
was constructed and this caused the returned string to be different
depending from which working directory it was called and not always
the intended binary path.
Using qt.conf has a fixed prefix relative to the binary path
inside the application bundle and therefore is easier to be used
with a relative path.
Reviewers: kbasan, msutcliffe
Reviewed By: msutcliffe
Differential Revision: https://dev.swift-project.org/D18
Summary:
This change adds <swiftInstall>/bin to the library lookup paths.
Without, QFactoryLoader is not able to find the Qt plugins
on Mac OS since on this platform the hard coded path defaults to
'foo.app/Contents/MacOS' for app bundles.
This change also adds the installation of QtPrintSupport framework which
is a dependency from cocoa platform plugin.
ref T48
Reviewers: kbasan, msutcliffe
Reviewed By: kbasan
Subscribers: jenkins
Maniphest Tasks: T48
Differential Revision: https://dev.swift-project.org/D15
Usage of this API was already discouraged, since all official
VATSIM packet handling should be in vatlib itself or for custom defined
packets in CNetworkVatlib. If a new custom packet needs to be added,
it should go into CNetworkVatlib directly and made available via normal
API methods to abstract the packets custom nature. The fact that
custom packets exist, should be kept internal. However, a debug message
is raised in case of an unknown custom packet in order to allow
detection and debugging.
refs #870
