handle dates with missing information, e.g. due to corrupted or missing text

[rlskoeser]

comment referencing these lines in the tests:

  # should we infer unknown month? or raise an exception?
  # assert str(Undate(2022, day="2X")) == "2022-XX-2X"  # currently returns 2022-2X
  # assert str(Undate(2022, day=7)) == "2022-XX-07"   @ currently returns 2022-07

I could see a situation with a corrupted text where we legitimately only know the year and day of the month, but we can't do much with the additional day info in this case. I don't think it should error; it's also unlikely we can infer the month in this situation. Is it possible to bump to the known granularity (year) for calculation purposes, and leave the day in a string rendering of the undate?

Originally posted by @ColeDCrawford in #36 (comment)

questions:

• does it make sense to raise an exception if you try to parse or export a date like this in a format that doesn't support this level of partial information?
• what is the granularity of a date like this, where we know the year and day but not month? does year make sense, or do we need gradations of granularity (year is certain, day is certain but month is unknown so day is only not fully known)

---

• switch default format from ISO8601 to EDTF
• update ISO8601 format method to raise an exception (ValueError?) when used to serialize unsupported date

[rlskoeser]

I think this behavior is a bug in the ISO8601 formatter, which doesn't support this case (unknown month with known date). I think the EDTF parser/formatter is far enough along that we could switch to make that one the default - it handles a lot more cases in terms of ambiguity and missing information. And then the ISO8601 parser should throw an exception if you try to use it to format a date that it can't handle, like year + day but no month.

I'll add a checklist to the issue with this proposed solution.