EDIT

The TimePeriodParser already supports YYYY and YYYY-MM-DD.

However, YYYY-MM is not correctly recognized and there is a reason for it. In literature and most data to parse XXXXX-XX is used as a real period e.g. 1801-03 more often means 1801-1803 then March 1801. So the parser may become ambiguous here.
It is difficult to solve this ambiguity.

Some solutions:

• If the 3rd and 4th digit of the year are larger then 12 or not smaller then the second part it is expected that the ISO 8601 date is meant. Otherwise use the period interpretation. This is helpful if one does not know which format might be meant, e.g. in the TaxEditor time period parser.
• Offer explicit method to parse certain formats, such as parseIso8601() or parseStartEndPeriod() or parseSingleDate() if one knows that a time period is a single date only and not a real period.
• Use separate parser classes for certain formats
• Allow to pass the expected format as a parameter
• Allow ordering priority of certain formats by the user
• TBC

Refer also to #6564#note-2 for further discussion of ambiguity.