On 8/26/2013 7:30 PM, Thiago Macieira wrote:
On segunda-feira, 26 de agosto de 2013 17:42:58, Calogero Mauceri wrote:
QDateTime myDateTime = QDateTime::fromTime_t(f_mtime);
The date time printed doing a myDateTime.toString() is
Wed Dec 5 12:36:18 2007
Retrieving the last modified
On Tuesday 27 August 2013 10:19:06 Calogero Mauceri wrote:
On 8/26/2013 7:30 PM, Thiago Macieira wrote:
On segunda-feira, 26 de agosto de 2013 17:42:58, Calogero Mauceri wrote:
QDateTime myDateTime = QDateTime::fromTime_t(f_mtime);
The date time printed doing a myDateTime.toString() is
On terça-feira, 27 de agosto de 2013 10:19:06, Calogero Mauceri wrote:
Unfortunately the problem is still there even if I force a toUTC()
conversion for both QDateTime, either the one initialized from time_t or
the one returned by QFileInfo :/.
Similarly
QDateTime dtFromTime_t =
When converting time from UTC to local time, Windows uses the *current*
state of daylight saving, not one that was active at the time the
original timestamp is pointing to.
On 08/27/2013 01:55 PM, Frank Hemer wrote:
On Tuesday 27 August 2013 10:19:06 Calogero Mauceri wrote:
On 8/26/2013 7:30
On terça-feira, 27 de agosto de 2013 21:40:29, Constantin Makshin wrote:
When converting time from UTC to local time, Windows uses the *current*
state of daylight saving, not one that was active at the time the
original timestamp is pointing to.
Hmm... we have two versions of the code:
From
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx
The MSDN library states:
To account for daylight saving time when converting a file time to a local
time, use the following sequence of functions instead of using
FileTimeToLocalFileTime:
FileTimeToSystemTime
(re-sending to the list, sorry for the mistake)
One key is in the Remarks section of
SystemTimeToTzSpecificLocalTime()'s documentation
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms724949(v=vs.85).aspx):
The SystemTimeToTzSpecificLocalTime function may calculate the local time
On terça-feira, 27 de agosto de 2013 22:17:07, Constantin Makshin wrote:
In MSVC's runtime library — yes, gmtime() is broken.
From MSDN (http://msdn.microsoft.com/en-us/library/vstudio/0z9czt0w.aspx):
Return Value
A pointer to a structure of type tm. The fields of the returned structure
On terça-feira, 27 de agosto de 2013 22:59:44, Constantin Makshin wrote:
Windows can store information about daylight saving transitions for past
years, but always uses one for the current year. And since daylight
saving transition dates and time tend to slightly drift from year to
year,
One key is in the Remarks section of
SystemTimeToTzSpecificLocalTime()'s documentation
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms724949(v=vs.85).aspx):
The SystemTimeToTzSpecificLocalTime function may calculate the local time
incorrectly under the following conditions:
One other note:
And since daylight saving transition dates and time tend to slightly drift
from
year to year, there's absolutely no guarantees of getting correct time
conversion results; in general case 1-hour error is nearly inevitable.
The timezone structure on Windows tracks the ST-DT
The original Calogero's message mentioned a file from December 2007, a
date outside of DST (unless there's a country that uses DST during
winter). Now it's August, so the DST is active and during UTC - local
time conversion Windows adds that 1 hour Calogero is seeing. DST gets
incorrectly applied
Technically, it is meant to be public. It closes the QIODevice so you
can no
longer read from it or write to it.
Actually, isn't rely on the interface, not
implementation the primary idea of inheritance?
QIODevice::close() - closes the device
when
QTemporaryFile::close() truncates and
On terça-feira, 27 de agosto de 2013 16:55:44, Alex Malyushytskyy wrote:
QIODevice::close() - closes the device
when
QTemporaryFile::close() truncates and repositions, but doesn't *close* the
file. If you really want to close, destroy the object or force it to open a
new
file (with a new
I agree that explicit object deinitialization (closing files, freeing
memory, etc.) in the callee is a bad thing (implicit through destructors
or object's management of its [internal] data is OK IMHO).
bar() was just a hypothetical example with the idea rely on the
[expected] behavior of the
Well, after some thoughts and looking at Qt 4.8 source code (Gitorious,
at least its web interface, was closed for maintenance yesterday in the
evening) my guess is that the problem is caused by Microsoft's
implementation of localtime() (QDateTime::fromTime_t() ends up in
utcToLocal() which on
On quarta-feira, 28 de agosto de 2013 08:51:46, Constantin Makshin wrote:
Well, after some thoughts and looking at Qt 4.8 source code (Gitorious,
at least its web interface, was closed for maintenance yesterday in the
evening
A better browser:
Damn, I just realized that I won't be able to test MSVC's localtime()
because Russia isn't using DST transitions since 2011, making it impossible
to distinguish DST is not used for past years from localtime()
completely ignores daylight saving information.
Someone else has to do it.
On Aug 28,
On quarta-feira, 28 de agosto de 2013 09:20:30, Constantin Makshin wrote:
Damn, I just realized that I won't be able to test MSVC's localtime()
because Russia isn't using DST transitions since 2011, making it impossible
to distinguish DST is not used for past years from localtime()
completely
19 matches
Mail list logo
