datetime.date object has no attribute astimezone

[10b14224cc]

I get the following error with the new version of radicale:

[2024-05-04 01:57:32 +0200] [539526/Thread-80 (process_request_thread)] [ERROR] An exception occurred during REPORT request on '/raffaele/901469ab-d739-9859-86bd-6f0c1334d5b2/': 'datetime.date' object has no attribute 'astimezone'

[SpiritCroc]

I needed a quick fix for this, so I went into app/report.py and changed the place where _expand() was called to a try-except, i.e.

try:
    expanded_element = _expand(
        element, copy.copy(item), start, end)
    found_props.append(expanded_element)
except Exception as e:
    logger.warning("Expand failed: %s ", e)
    found_props.append(element)

If I understand the issue correctly, 3.2.0 added support for expanding recurring events, but hasn't considered full-day events stored as date instead of datetime, so a proper fix should change the logic to account for that.

[pbiering]

@metallerok : can you please dig into, potentially #1293 was incomplete

[pbiering]

@metallerok : can you please dig into, potentially #1293 was incomplete

@metallerok : did you have already time to look into?

[metallerok]

yes, i am trying

[pbiering]

@SpiritCroc / @10b14224cc : can you please test latest master now?

[SpiritCroc]

Thanks for looking into this!
With master, now the query doesn't return a server error anymore, which is great! However, the events appear to no longer be reported as full-day events. At least my calendar script used to say something like

"all day 2024-05-28", now it says something like
"2024-06-11 02:00 - 02:00"
which I assume comes from living in UTC+2, but would be nice if the event was still reported as "full day" (not sure if caldav has a flag for whole-day events or one needs to omit times or how this is decided under the hood).

[metallerok]

Do you mean that expanded events return datetime, not date? Expanded events return the UTC dateime in accordance with the rfc https://www.rfc-editor.org/rfc/rfc4791#section-9.6.5

[metallerok]

And the vobject.RecurringComponent does not know how to work with all-day events and by default converts them to datetime https://github.com/skarim/vobject/

[SpiritCroc]

Do you mean that expanded events return datetime, not date?

Yes, the original event didn't have a time, so the time I now get displayed is "invented", while before the patch it was showing fine as full-day event.

And the vobject.RecurringComponent does not know how to work with all-day events and by default converts them to datetime https://github.com/skarim/vobject/

Hm I see, that's unfortunate.

Without reading too much into the rfc it feels wrong to me to add an arbitrary time when expanding events that don't have time, I wonder if it'd be feasible to just convert the datetime results back to date after expanding (if it was only a date to begin with) and before returning.

[pbiering]

@SpiritCroc @metallerok : I had the plan releasing 3.2.1 today, has this issue still to be considered as a blocker? Then I will wait...

[SpiritCroc]

It's not a blocker in my book - considering that in the previous release accessing the calendar resulted in an internal server error, the new behaviour still seems like an improvement worth releasing.

[pbiering]

@SpiritCroc : can you test latest master now?

[SpiritCroc]

Looks perfect now on my end, thank you very much!