Qt::RFC2822Date inconsistencies, limitations and difficulties

The Qt::RFC2822Date format claims to be based on RFCs 2822 (an update of 822, superseded by 5322), 850 and 1036 (an update of 850, superseded by 5536).
These define formats for date-times; but we use this enum member also when parsing and serialising dates and times separately, a use-case not countenanced by any of these RFCs.
Issues, inconsistencies and incompatibilities:

• The actual parser makes some spaces in the format optional independent of whether an adjoining optional field is present. Thus " 13 Dec 2019 12:00:00+01:00" will be parsed as a valid date-time (despite lacking a space before the TZ offset), where " Fri, 13 Dec 2019 12:00:00 +01:00" will not (due to leading space: although the code uses QString::indexOf(), the regular expressions used are anchored at the start - but not at the end - so the leading space prevents a match; the trailing space is no problem, though).
• In support of the use-case of parsing a date without a time, the time and zone-offset are treated as optional: there is no support for this in any of the RFCs mentioned (only the day-of-week is optional, in the format the RFCs say to use); and the date is not treated as optional in support of parsing a time without a date, so we cannot round-trip times.
• The optional day-of-the-week indicator is not checked when given, so "Wibble, 13 Dec 2019" will be parsed entirely successfully as a date. (The implementation does at least use the C-locale's standard month abbreviations, as mandated by the RFCs.)
• RFC 2822 mentions (as obsolete) a short list of time-zone abbreviations that should be recognised (with specific meanings for each, notwithstanding that there may be several other zones sharing any given abbreviation); these are still recognised in 5322. The QDateTime code makes no attempt to support these. This probably isn't worth changing.

I note, further, that the NetNews RFCs (850, 1036) allude to compatibility with getdate(3), whose behaviour depends on the contents of a file named by environment variable DATEMSK; this file's lines are arbitrary format specifiers recognised by strptime(3), each of which getdate() tries in turn until strptime() succeeds on the string to be parsed. I interpret the RFCs' mention of compatibility with it as constraining the format to be one representable by some strptime() format specification; this is, none the less, a very loose requirement. These RFCs mention one format, the ddd MMM dd hh:mm:ss yyyy ±tzoff one currently supported (with some parts optional), as an example of a format that should be recognised but should not be generated by conforming software. This format is no longer mentioned in RFC 5536, which only make reference to RFC 5322.

I'll probably notice further infelicities the longer I keep looking at this.
Some of these cannot sensibly be fixed except at a major version update, i.e. Qt 6.
Others can perhaps be fixed in 5.15.