4b4bd6ab98
This avoids so many complications. The prior code, using SystemTimeToTzSpecificLocalTime(), lead to unhelpful results when the QDateTime() implementation used MS-POSIX's defective mktime(). Although SystemTimeToTzSpecificLocalTime() is actually more correct, we were getting inconsistent results by mixing the two: and eliminating the use of mktime() turns out to be decidedly tricky. So, to avoid inconsistency, stick with a UTC time (which is what FILETIME is defined as). Change QFileInfo's methods to explicitly convert .toLocalTime() where appropriate and document that these methods do indeed return local time (as we conjecture has been taken for granted by callers). Also added a regression test for the reported case of this going wrong. A time-stamp from before Russia's (permanent, not DST) change of TZ could end up inconsistently handled between file-system meta-data and raw date-time APIs, due to cross-talk between different MS-Win time APIs. [ChangeLog][QtCore][QFileInfo] Made sure that all file lifecycle times are in local time. This was probably true before, but is now explicit. Task-number: QTBUG-48306 Change-Id: Ic0b99d25c4168f623d31967bc60665c0c4f38a14 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||
---|---|---|
.. | ||
animation | ||
arch | ||
codecs | ||
doc | ||
global | ||
io | ||
itemmodels | ||
json | ||
kernel | ||
mimetypes | ||
plugin | ||
statemachine | ||
thread | ||
tools | ||
xml | ||
configure.json | ||
corelib.pro | ||
eval.pri | ||
Qt5Config.cmake.in | ||
Qt5CoreConfigExtras.cmake.in | ||
Qt5CoreConfigExtrasMkspecDir.cmake.in | ||
Qt5CoreConfigExtrasMkspecDirForInstall.cmake.in | ||
Qt5CoreMacros.cmake | ||
Qt5CTestMacros.cmake | ||
Qt5ModuleLocation.cmake.in | ||
Qt5ModuleLocationForInstall.cmake.in | ||
QtCore.dynlist | ||
qtzlib.pro |