TODO.end = TODO.start if no DURATION/DUE is given

[niccokunzmann]

This should be checked in a test: TODO.end = TODO.start if no DURATION/DUE is given

• create a test that checks this case
• change code if needed

Context: The RFC makes a statement about the Event but there is nothing about the TODO. I doubt though that the TODO is endless but I do not know.

@tobixen - you work more with TODOs. It is a case that TODOs have only a DTSTART. What is the expected end of such a TODO? The same as the start or is it endless? (None)

Originally posted by @niccokunzmann in #896 (comment)

[SashankBhamidi]

Found it. Lines 200-202 in todo.py are doing start + 1 day for dates but just start for datetimes:

if is_date(start):
    return start + timedelta(days=1)
return start

This came from consolidating Event/Todo logic in #896. Events need the +1 day but looks like TODOs shouldn't.

Fix: for TODOs, change both the date and datetime cases to return start. Add tests to verify todo.end == todo.start for both dates and datetimes (keeping existing Event behavior).

@niccokunzmann @tobixen does this look right?

[niccokunzmann]

I do not know what "both cases" means specifically. But yes, the fix would include two tests, one for event and one for todo, testing that that special case is handled accordingly and differently.

[SashankBhamidi]

I do not know what "both cases" means specifically. But yes, the fix would include two tests, one for event and one for todo, testing that that special case is handled accordingly and differently.

Apologies for being vague, I've edited the comment.

[niccokunzmann]

Yes, that is the place in the code that needs changing.

[SashankBhamidi]

I'll add two tests:

1. Event with date-only DTSTART returns start + 1 day
2. Todo with date-only DTSTART returns start

Then modify get_end_property() to check component type before applying the +1 day logic.