[Development] QDateTime::currentDateTime().toString(Qt::SystemLocaleLongDate) returns as if the DST was still in effect

[Jan Kundrát]

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