Details
-
Task
-
Resolution: Unresolved
-
P2: Important
-
None
-
5.14, 6.8
-
None
-
-
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
- blocks
-
QTBUG-129287 QDateTime fails to parse some dates
- Closed
- covers
-
QTBUG-110669 Q/Date/Time: align unquoting format strings for both from/toString()
- Open
- is duplicated by
-
QTBUG-111055 Consider adding a QDateTimeFormatter class
- Closed
- is required for
-
QTBUG-124465 QDate::fromString very slow in 6.7.0
- Closed
-
QTBUG-70516 Extend Qt's support for CLDR date/time formatting
- Open
- relates to
-
QTBUG-46843 Way to change base year for QDate::fromString 2 digit year parsing
- Closed
-
QTBUG-122228 Gaps in date-time format string support
- Reported
-
QTBUG-82886 Qt::DefaultLocaleShortDate / QLocale::ShortFormat date parsing doesn't deal with 4-digit years
- Open
-
QTBUG-79803 QDateTimeEdit handles DST changes incorrectly
- Closed
-
QTBUG-80417 QDateTimeEdit cannot handle OffsetFromUTC or TimeZone as time-spec
- Closed
-
QTBUG-97489 [REG 6.2 -> 6.3.0] QDateTime::fromString slow at handling large input
- Closed
-
QTBUG-91070 Extend ISO 8601 support to include years BCE and > 9999 CE.
- Reported
-
QTBUG-114172 Add support for RFC 9557 time-zone suffixes in QDateTime
- Reported
-
QTBUG-81056 Add QDateTimeFormat based on CLDR's format strings
- Open
-
QTBUG-87111 Adapt qdatetimeparser to non-"Latin" number systems
- Open
-
QTBUG-36601 QDateTime::fromString is not able to parse spaced formats
- Reported
-
QTBUG-79916 QDateTime format should support DST char
- Reported
-
QTBUG-105985 Add format string option for week number
- Reported
-
QTBUG-1138 QDateTimeEdit stepping behavior
- Closed