Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-83075

QDateTimeParser fails to set correct zone when parsing with a zone specified

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.15.0 RC
    • 5.14.0
    • Core: Date/Time
    • None
    • All
    • 21
    • 76054516047d8efb8529443830bb4d9ddf01010f (qt/qtbase/5.15)
    • Qt6_Foundation_ Sprint 6, Qt6_Foundation_ Sprint 7

    Description

      When a date-time format string includes a t specifier for the time-zone, and the string being parsed contains a time-zone specifier, the returned time-zone object should have its timeSpec() and related properties set to match;

      • if the zone specifier is 'Z' (for "Zulu time", an alias for UTC), UTC or ±0:0, timeSpec() should be Qt::UTC;
      • if the zone specifier is any other UTC-offset zone identifier, or a ±hh:mm offset, timeSpec() should be Qt::OffsetFromUTC
      • if the zone specifier is a zone-name, timeSpec() should be Qt::TimeZone and timeZone() should report the correct zone.

      Experiment reveals that, at least in the 'Z' case, this is not what happens.

      Also, the t format-specifier for zone is documented in the wrong place - it is documented in the QTime::fromString() with string format (not enum); it should actually be documented in the matching QDateTime::fromString(), since that's the only case where it's meaningful. The parser should also only support it for the date-time case.

      Attachments

        Issue Links

          For Gerrit Dashboard: QTBUG-83075
          # Subject Branch Project Status CR V

          Activity

            People

              agolubev Andrei Golubev
              Eddy Edward Welbourne
              Maurice Kalinowski Maurice Kalinowski
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes