This seems to be stored as the "start" value in the meta table of the event.

Ok, can confirm:

• https://fahrplan.events.ccc.de/congress/2024/fahrplan/schedule/export/schedule.xml has "2024-12-27" as start
• https://api.events.ccc.de/congress/2024/schedule.xml has "2024-12-27T09:30:00+00:00" as start

Frab defines this as xs:date: https://github.com/frab/schedule.xml/blob/master/schema/schedule.xml.xsd#L20C1-L20C73

But their own schema make it more complicated: https://raw.githubusercontent.com/voc/schedule/master/validator/xsd/schedule.xml.xsd

Would you be open to accepting their format if I send over a patch? I could normalize it when reading the file initially.

Thank you for reporting this!

The problem is here. My fix would be to expand the checks to support more formats, but I'd like to have a better and more robust solution.

I'm open to any patch which improve the really fragile xml parser :)

Main point is however to continue support any strange kind of xml which passes as Pentabarf...

.. I suspect that "if" is there for dates coming from events in ical format. Normalizing source values would be the right thing to do, indeed..

I've pushed a quick fix to this as commit 5df8ab8a86 It's still bad, so I'll leave this ticked opened as a reminder.

Oh I see. I didn't think about fixing it in that way.

What would your preferred fix then look like ?

I can confirm that it works with the 0.8.0 from flatpak.

I can confirm that it works with the 0.8.0 from flatpak. 👍

What would your preferred fix then look like ? I would like to have a cleaner code which parsers various schedule xml flavours (and ics) in a well-defined internal format, because that code is quite a mess.. I have to admit I'm not good in writing clean code...

I have to say my impression was that your codebase looks quite well structured, so don't be too hard on yourself.

It's also quite tricky to parse various badly defined flavors. There will always be ugly special cases.