You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# 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?
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)
The text was updated successfully, but these errors were encountered:
rlskoeser
changed the title
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? Can't remember
handle dates with missing information, e.g. due to corrupted or missing text
Oct 23, 2023
comment referencing these lines in the tests:
Originally posted by @ColeDCrawford in #36 (comment)
questions:
The text was updated successfully, but these errors were encountered: