Added handling of null DTSTART of recurring instances

[ArnyminerZ]

Purpose

Fixes #1265 by correctly handling situations where dtstart is null.

Short description

Handled nullability of DTSTART of recurring instances by setting the local value to null, which would re-create the local instance.

Checklist

• The PR has a proper title, description and label.
• I have self-reviewed the PR.
• I have added documentation to complex functions and functions that can be used by other modules.
• I have added reasonable tests or consciously decided to not add tests.

[ArnyminerZ]

I've also added a log message so that if we find some data missing we can know what is it all about. If you don't find it necessary we can remove it.

[rfc2822]

Handled nullability of DTSTART of recurring instances by setting the local value to null, which would re-create the local instance.

What would that mean in our case? Do I understand it correctly that

• the main VTODO (without RECURRENCE-ID) is normally created/updated,
• and what happens with the VTODO with RECURRENCE-ID;TZID=America/New_York:20250228T130000? It seems to be added instead of updated in the code – is it deleted before so that it doesn't add a new instance for every sync?

[sunkup]

How about adding a test to verify and document correct behaviour?

[ArnyminerZ]

How about adding a test to verify and document correct behaviour?

I've been looking at how to test this properly, and if I am not wrong, that would mean creating a new test class just like SyncManagerTest, but for JtxSyncManager, and checking whether it can handle those cases correctly right? @rfc2822 can correct me otherwise. I think it's actually a lot of code for just a "side-hustle".

Of course we can add it, but is it really worth it?

[sunkup]

Of course we can add it, but is it really worth it?

I'd say yes definetly - If the test is relevant we should add it and in this case I find it highly relevant to properly understand (#1336 (comment)), clamp and document the newly added behaviour.

[rfc2822]

At least we have a specific iCalendar we could test with… it's surely at least worth the try. If it's absolutely too cumbersome we can still cancel it then

What would that mean #1265 (comment)? Do I understand it correctly that

• the main VTODO (without RECURRENCE-ID) is normally created/updated,
• and what happens with the VTODO with RECURRENCE-ID;TZID=America/New_York:20250228T130000? It seems to be added instead of updated in the code – is it deleted before so that it doesn't add a new instance for every sync?

Did you already had a look at that?