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

Rewrite QDateTimeParser

    XMLWordPrintable

Details

    • Task
    • Resolution: Unresolved
    • P2: Important
    • None
    • 5.14, 6.8
    • Core: Date/Time
    • None
    • All
    • 100
    • 3e25203d4 (dev), 4408d077a (6.8)
    • Foundation Sprint 113, Foundation Sprint 114, Foundation Sprint 115, Foundation Sprint 116, Foundation Sprint 117, Foundation Sprint 118, Foundation Sprint 119, Foundation Sprint 120

    Description

      The present QDateTimeParser code reads its string sequentially, using information from earlier in the string, along with a "guessed" date, to help it make sense of each field as it comes to it in succession. This is a pretty poor way to work, when information later in the string may over-ride the guesses being used to make sense of what appeared earlier; as a result, it has all sorts of funky heuristics about cancelling and over-riding earlier guesses and heuristics.

      The format string we're using to guide parsing could be used to split up the string at the beginning, before we look at the content of the resulting fragments any more closely than a basic lexical "is it a digit" or "is it the separator we expect here" level. We could then extract the time-zone or offset (when given) first, no matter where in the string it appears (very often at the end, exactly the worst place for it with the present sequential approach), then extract the year (again, often late in the string), then month (using the year, for those calendars for which it's relevant, to guide us), then the day of month (now that we know how many days there are in the month) and so on. It'll surely be more complicated than that, but the general approach of splitting it up first and then making sense of the pieces in an order that suits us would surely be more robust (and better able to handle complications such as I expect we'll hit with some of the more interesting calendars).

      It is even respectably likely that such an approach would prove faster than the present approach, as it would need to do less back-tracking to correct guesses made earlier. It would also avoid instantiating any QDateTime instances until it had all the information it needs to do so, instead of instantiating one (or more) per field of the date-time text, as it is parsed. When it does instantiate a QDateTime, furthermore, it won't attempt to resolve any zone-specific strangeness (DST, &c.) unless it actually needs to (instead of doing so over and over again until it discovers it was all unnecessary, as in the present implementation), and even then it will only do so once, for the date-time the string actually does represent (rather than for a succession of different date-times, each taking into account one more field than the previous).

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-129287 QDateTime fails to parse some dates

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Closed
          covers

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-110669 Q/Date/Time: align unquoting format strings for both from/toString()

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Open
          is duplicated by

          Suggestion - Public suggestions QTBUG-111055 Consider adding a QDateTimeFormatter class

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Closed
          is required for

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-124465 QDate::fromString very slow in 6.7.0

          • P1: Critical - Urgent and Important, will STOP the release if matched with set FixVersion field. This includes regressions from the last version that are not edge cases; Data loss; Build issues; All but the most unlikely crashes/lockups/hanging; Serious usability issues and embarrassing bugs & Bugs critical to a deliverable. This is the highest possible priority for requirements.
          • Closed

          Task - A task that needs to be done. QTBUG-70516 Extend Qt's support for CLDR date/time formatting

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Open
          relates to

          Suggestion - Public suggestions QTBUG-46843 Way to change base year for QDate::fromString 2 digit year parsing

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-131456 [Regr:6.4->6.5] Significant performance degradation of converting UTC from/to local time

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Reported

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-122228 Gaps in date-time format string support

          • P4: Low - Would be nice to fix, but it's not very important.
          • Reported

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-82886 Qt::DefaultLocaleShortDate / QLocale::ShortFormat date parsing doesn't deal with 4-digit years

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-79803 QDateTimeEdit handles DST changes incorrectly

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-80417 QDateTimeEdit cannot handle OffsetFromUTC or TimeZone as time-spec

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. QTBUG-97489 [REG 6.2 -> 6.3.0] QDateTime::fromString slow at handling large input

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Closed

          Task - A task that needs to be done. QTBUG-91070 Extend ISO 8601 support to include years BCE and > 9999 CE.

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Reported

          Task - A task that needs to be done. QTBUG-114172 Add support for RFC 9557 time-zone suffixes in QDateTime

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Reported

          Technical task - A technical task. QTBUG-81056 Add QDateTimeFormat based on CLDR's format strings

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Open

          Task - A task that needs to be done. QTBUG-87111 Adapt qdatetimeparser to non-"Latin" number systems

          • P2: Important - Urgent, should be fixed, but will not stop the release.
          • Open

          Suggestion - Public suggestions QTBUG-36601 QDateTime::fromString is not able to parse spaced formats

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Reported

          Suggestion - Public suggestions QTBUG-79916 QDateTime format should support DST char

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Reported

          Suggestion - Public suggestions QTBUG-105985 Add format string option for week number

          • P4: Low - Would be nice to fix, but it's not very important.
          • Reported

          Suggestion - Public suggestions QTBUG-1138 QDateTimeEdit stepping behavior

          • P3: Somewhat important - Should be fixed, but doesn't affect the release in any way.
          • Closed
          For Gerrit Dashboard: QTBUG-77948
          # Subject Branch Project Status CR V
          599060,3 Address problems with date-time parsing near bounds tqtc/lts-6.5 qt/tqtc-qtbase Status: NEW 0 0

          Activity

            People

              Eddy Edward Welbourne
              Eddy Edward Welbourne
              Vladimir Minenko Vladimir Minenko
              Alex Blasche Alex Blasche
              Votes:
              3 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 5 weeks
                  5w
                  Remaining:
                  Remaining Estimate - 5 weeks
                  5w
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                  Gerrit Reviews

                    There is 1 open Gerrit change