Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Auto) fixing invalid icalendar (components) #223

Closed
geier opened this issue Apr 22, 2017 · 2 comments
Closed

(Auto) fixing invalid icalendar (components) #223

geier opened this issue Apr 22, 2017 · 2 comments

Comments

@geier
Copy link
Collaborator

geier commented Apr 22, 2017

As already recently discussed in #222, should we try to fix broken icalendars and/or icalendar components?

The issue in #222 were VTIMEZONE's OFFSETs > 24h which should be minutes (e.g., TZOFFSETFROM:+5744 => TZOFFSETFROM:+005744) (I'm inclined to say no, as it's hard to guess what was really meant).

Further issues are VEVENTs without a UID (see pimutils/khal#632) or DTSTART == DTEND.

@stlaz
Copy link
Collaborator

stlaz commented Apr 24, 2017

I don't think we should try to be clever with invalid inputs. After all, we are but a parser, it's our duty to warn the user that their input is not correct, and fail in that case.
We can have some error recovery in case the parsing should not be strict but the best thing we can do is to leave the input untouched, not trying to fix it. The user should fix it themselves in such case. A warning that their input is not correct should still be issued, though.

@gasull
Copy link

gasull commented Nov 19, 2019

I don't think we should try to be clever with invalid inputs.

Many HTML parsers, like HTML Tidy, attempt to fix invalid HTML, or have the option to do so. icalendar should do the same.

@collective collective locked and limited conversation to collaborators Aug 30, 2023
@niccokunzmann niccokunzmann converted this issue into discussion #536 Aug 30, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants