Hi,
I'm on x86_64 Gentoo Linux (timezone-data 2012c, glibc 2.15-r2), using Qt
4.8.3. My timezone is set to Europe/Prague via the /etc/localtime file. I do
not have the TZ environment variable set.
Calling qDebug() <<
QDateTime::currentDateTime().toString(Qt::SystemLocaleLongDate); shows me
correct date and time (i.e. the hours displayed match reality), but instead of
"CET" as expected, the timezone is shown as "CEST". Calling bash's `date`, both
without any env var modifications and also with an explicit TZ=Europe/Prague,
shows both correct hours and also the correct "CET" timezone.
I've dug into Qt's sources and it looks that the brokenDown (as of
qdatetime.cpp, line 4089) indeed refers to CEST:
(gdb) print *brokenDown
$3 = {tm_sec = 20, tm_min = 33, tm_hour = 16, tm_mday = 29, tm_mon = 5, tm_year
= 112, tm_wday = 5, tm_yday = 180, tm_isdst = 1, tm_gmtoff = 7200, tm_zone =
0x907b30 "CEST"}
This machine has been running for a few days, the last reboot has definitely
happened before the DST changeover.
However, `mitchc` on #qt kindly confirms that he also gets "CEST" in
QDateTime's output, even after a reboot since the DST change. He says that
brokenDown's tm_isdst is *not* set for him.
So, given that `date` reports the time correctly, I suspect that Qt is using
some strange way of obtaining the TZ information. Do you have any ideas about
what is confusing it to believe that DST is still active on this box? Please
note that the actual hours being displayed are always correct, it's just the TZ
indication which is off.
With kind regards,
Jan
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
