[Bug] Event.new doesn't set a DTEND when neither it nor DURATION are provided

[stevepiercy]

Describe the bug

According to the iCalendar specification for VEVENT:

For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE value type but no "DTEND" nor "DURATION" property, the event's duration is taken to be one day. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME value type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property.

icalendar doesn't set this property.

To reproduce

import icalendar
import datetime as dt
import zoneinfo
from icalendar import Event

calendar = Calendar.new()
event = Event.new(
    start=dt.datetime(2026, 3, 21, 6, 30,0, tzinfo=zoneinfo.ZoneInfo("Europe/Berlin")),
)
calendar.add_component(event)
print(calendar.to_ical().decode())

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//collective//icalendar//7.0.3.dev78//EN
UID:898b4925-3576-4893-a82f-0f01eaedb6a9
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20260321T063000
DTSTAMP:20260312T203408Z
UID:e07a90f5-bee8-4fab-8622-9202eb2d9090
CATEGORIES:
END:VEVENT
END:VCALENDAR

Expected behavior

A calendar event should set its DTEND property to the DTSTART property when neither DTEND nor DURATION are set.

Environment

• Operating system: macOS 13.7.8 (22H730)
• Python version: Python 3.14
• icalendar version: 7.0.3.dev78

Additional context

See plone/volto#7993 (comment)

@SashankBhamidi @niccokunzmann @tobixen @abe-101 I'd like your interpretation of the RFC to verify what I think is the correct behavior before anyone works on this issue. Thank you!

[stevepiercy]

BTW, this is a good reason not to just copy paste the RFC into our docstrings because it misleads icalendar users into believing that the implementation is in fact compliant. The sooner we implement #1244, the better.

[tobixen]

I actually though this wasn't explicitly specified in RFC5545, but it is specified in the description of how search (REPORT) should work in the caldav protocol (RFC4791). An event with DTSTART set but no DTEND/DURATION should be considered to have zero duration if DTSTART is a timestamp, and one day duration if DTSTART is a day.

My expectation is that event = Event.new(start=xxx) would give me an event with an explicit DTSTART and an implicit DTEND. From the description above, that seems to be the way it works today - so, not a bug. My expectation is that event.end will give me the implicit end date/timestamp.

[tobixen]

>>> from icalendar import Event
>>> from datetime import date
>>> event = Event.new(start=date.today())
>>> event.end
datetime.date(2026, 3, 13)
>>> event.start
datetime.date(2026, 3, 12)

Works pretty much as I would expect it to work.

[stevepiercy]

Thanks for checking. It appears that dates only work as expected, but not datetimes. The latter should be tested with and without timezones, too.

I think that the reason for the RFC saying the same datetime for DTEND as DTSTART in this case is because of daylight saving time shifts, which would be not fun to accommodate.