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
    • Foundation Sprint 113, Foundation Sprint 114, Foundation Sprint 115, Foundation Sprint 116, Foundation Sprint 117

    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

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              Eddy Edward Welbourne
              Eddy Edward Welbourne
              Vladimir Minenko Vladimir Minenko
              Alex Blasche Alex Blasche
              Votes:
              3 Vote for this issue
              Watchers:
              7 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 are no open Gerrit changes