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

2012-10-30 Thread Mitch Curtis
On Monday, October 29, 2012 09:09:48 AM Thiago Macieira wrote: It's got to be a glibc bug. We only do: tzset(); localtime(); Since we don't do anything special, I'm forced to conclude that the bug is in glibc. Jan, if you do report it to whoever is responsible for glibc, you

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

2012-10-29 Thread 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

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

2012-10-29 Thread Mitch Curtis
On Monday, October 29, 2012 04:28:17 PM Jan Kundrát wrote: 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. Mine looks like: tm_gmtoff = 3600 tm_hour = 16

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

2012-10-29 Thread Thiago Macieira
On segunda-feira, 29 de outubro de 2012 16.28.17, Jan Kundrát wrote: 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?