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 desktop systems uses localtime() or its variations to get broken down timestamp representation) not applying/providing DST information. But SystemTimeToTzSpecificLocalTime(), used internally by QFileInfo time retrieval methods, adjusts its output according to the current state of daylight saving, leading to that 1-hour difference Calogero is experiencing.
I'll probably test this theory in a few hours when I get to a Windows machine. On 08/28/2013 02:53 AM, Thiago Macieira wrote: > On quarta-feira, 28 de agosto de 2013 01:01:55, Constantin Makshin wrote: >> 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 because it's active at the moment of conversion, >> although it wasn't used at the moment the original timestamp represents. > > That would support the theory that gmtime is broken on Windows, that it > doesn't apply the DST rules at all. > > I don't have time to do further testing on this, so if someone can, it would > be appreciated. Also, please report the issue in the Qt issue tracker > (http://bugreports.qt-project.org) so it doesn't get forgotten. > > PS: I don't know of any country that does DST in Winter. I do know of > countries that have Summer in December, though, and I know of regions that do > reverse DST during Winter.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
