QDateTime::toString() strange behaviour with timezone



  • 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?



  • @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.



  • 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 :)


  • Qt Champions 2016

    @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. :)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.