Solved QDateTime::toString() strange behaviour with timezone

[the_]

Hi all,

In one of my Qt apps I show a formated date and time string in a label, updated every second.

datetimelabel->setText(QDateTime::currentDateTimeUtc().toString("yyyy-MM-dd hh:mm:ss t")+"\n"+QDateTime::currentDateTime().toString("yyyy-MM-dd hh:mm:ss t"));

When I run this app on my linux box (Qt5.5, clang) the date and time is displayed as
2016-04-14 09:50:57 UTC
2016-04-14 11:50:57 CEST

When I run the same code on Windows (Win8.1, same Qt Version with mingw) it displays
2016-04-14 09:50:57 UTC
2016-04-14 11:50:57 W. European Daylight Time

Is this intended behaviour or am i missing something?

[Paul Colby]

@the_ said:

Is this intended behaviour or am i missing something?

To me, this would be intended behaviour, but the docs don't explicitly call it out.

You'll notice that the QDateTime::toString docs do say, in multiple places:

Uses the system locale to localize the name, i.e. QLocale::system().

Although it doesn't say that explicitly for the t expression, nevertheless, looking at the code, internally QDateTime::toString does just:

return QLocale::system().toString(*this, format);

And the docs for QLocale::toString say:

Returns a localized string representation of the given dateTime

So the output would depend on your system locale, which is what I would have expected anyway.

You might try using QDateTime::timeZoneAbbreviation instead, like:

const QDateTime now = QDateTime::currentDateTime();
qDebug() << now.toString("yyyy-MM-dd hh:mm:ss") << now.timeZoneAbbreviation();

But even that function says:

Note that abbreviations may or may not be localized.

In the end, I understand your frustration, but timezone abbreviations really cannot be relied upon for consistency, IMO. There are so many issues such as overalapping abbreviations (where I live, "EST" is UTC+10, but to those in the US, its something like UTC-5), and variations between versions of the same OS, let alone across different platforms.

If you need it to be consistent, then I'd opt for something like Qt::ISODate. But as you're showing it in a label, it might be even better to respect the user's locale, and just use Qt::DefaultLocaleShortDate or Qt::DefaultLocaleLongDate?

Cheers.

[the_]

Hi @Paul-Colby

Thanks for your reply and explanation.

You might try using QDateTime::timeZoneAbbreviation instead, like:

const QDateTime now = QDateTime::currentDateTime();
qDebug() << now.toString("yyyy-MM-dd hh:mm:ss") << now.timeZoneAbbreviation();

But even that function says:

Note that abbreviations may or may not be localized.

now.timeZoneAbbreviation();

also says "W.European Daylight Time". I tested on several Windows Devices with different language settings. Its always the same long string, only different translations.

In the end, I understand your frustration, but timezone abbreviations really cannot be relied upon for consistency, IMO. There are so many issues such as overalapping abbreviations (where I live, "EST" is UTC+10, but to those in the US, its something like UTC-5), and variations between versions of the same OS, let alone across different platforms.

I am not really frustrated :) I can deal with that "feature" as I for my part usually do not use Windows. I just hope that others who use that OS can deal with this (for me) malformed datetime string. I just wondered why this happens.

The only frustrating thing is, that strftime() also returns the same "wrong" value. Digging a little bit deeper i found out, that running tzutil /l in the Windows Command Line does NOT return any short values for timezones.
Also, trying to use strftime() with %z , which should display the offset to UTC under windows does not what expected. Seems that on Windows there is no difference between %Z and %z (according to MSDN docs both return the name or abbreviation of the timezone, localized)

Cheers.

Cheers :)

[kshegunov]

@the_ said:

this (for me) malformed datetime string

Well, malformed would be pushing it a bit. If you are in need of a platform independent way of handling the timezone you'd give it as ISO 8601 date time - with the timezone offset; for any other purpose the text representation will be dependent on OS's locale settings. :)