Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Solved QDateTime::toString() strange behaviour with timezone

    General and Desktop
    qdatetime qt5.5
    3
    4
    6444
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • the_
      the_ last edited by

      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?

      -- No support in PM --

      1 Reply Last reply Reply Quote 0
      • P
        Paul Colby last edited by

        @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_ 1 Reply Last reply Reply Quote 2
        • the_
          the_ @Paul Colby last edited by

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

          -- No support in PM --

          1 Reply Last reply Reply Quote 0
          • kshegunov
            kshegunov Moderators last edited by

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

            Read and abide by the Qt Code of Conduct

            1 Reply Last reply Reply Quote 0
            • First post
              Last post