Accept DATE values with midnight time suffix

[arrizer]

Accept DATE values that include a midnight time suffix (YYYYMMDDT000000 or YYYYMMDDT000000Z).

Some calendar generators emit invalid VALUE=DATE values with a midnight time suffix. This is common in real-world ICS feeds. Strict parsing rejects these files even though the intent is unambiguous. Treating midnight time suffixes as dates improves interoperability without impacting valid DATE-TIME inputs.

[allenporter]

Hello, thank you for the contribution!

Generally, we do not have a goal of allowing malformed calendars to parse validation since we want to avoid this library itself creating invalid calendars and going undetected. If you can show this is part of the rfc5545 then let me know.

We do have an ical.compat module where we can allow some users of ical to opt in to have less strict parsing rules. If you'd to propose a compat module for this, I think that could be a possibility, though I would like to be more specific about which calendars are creating this and at least have some conviction that those calendars can't be fixed (e.g. ideally they'd fix their calendars to not be invalid rather than having every other calendar provider add workarounds)

[arrizer]

Hey! Thanks for taking a look. I proposed this change for a malformed calendar I tried to use in HomeAssistant, which is using this library to parse iCal files. Unfortunately I have no control over the source of this calendar. Since I noticed that macOS Calendar app accepts the malformed calendar, I thought there would be no harm in also making the parsing here a bit more lenient. I understand if you're hesitant to merge this of course, your call!

[allenporter]

My recommendation would be the ical.compat approach I mentioned so that we don't need to allow malformed calendars everywhere.

[allenporter]

Thanks again for the contribution and raising this! I've resolved this issue by implementing a date compatibility layer under the ical.compat module (matching the feedback here). MALFORMED DATE values with time suffixes will now be silently stripped and parsed successfully when compatibility mode is enabled.

You can track the implementation details in #625. Closing this PR in favor of that solution. Thank you.