Should "add event" create an all-day event if a time is not specified?

[davemcguire]

It seems to me that doing "plann add event" should create an "all day" event if a time isn't specified in the timespec. This is just my opinion, but it seems logical. (and it would solve a problem for me ;)) The difference in the ICS data would change from this:

DTSTART:20260207T050000Z

...to this:

DTSTART;VALUE=DATE:20260226
DTEND;VALUE=DATE:20260227

(I don't know if the DTEND is strictly necessary.)

Nice library, by the way!

[tobixen]

It seems to me that doing "plann add event" should create an "all day" event if a time isn't specified in the timespec.

It's some time since I was hammering on this ... I think this was the intention.

I can find this in the test code:

    @pytest.mark.parametrize("input", ["2012-12-12", "2011-11-11 11:11:11", datetime(2011, 11, 11, 11, 11, 11), date(2012, 12, 12), "+14d"])
    def testParseDt(self, input):
        tz.implicit_timezone = 'Europe/Helsinki'
        ts = parse_dt(input)
        if input == '+14d':
            assert ts > datetime.now().astimezone(tz.implicit_timezone)
        else:
            assert ts in (
                datetime(2011, 11, 11, 11, 11, 11, tzinfo=tz.implicit_timezone),
                date(2012, 12, 12))
        ts = parse_dt(input, return_type=datetime)

Let's have a look ...

$ plann --config-section=work add event 2026-01-07 "it's Saturday and I will be out of the office"

But it seems not to be working (I should make that pager thing opt-in for small data sets) ...

$ plann --config-section=work add event "it's Saturday and I will be out of the office" 2026-01-07 
uid=c9ff48a6-039c-11f1-94c1-0aa22df30662

308498 [Fri Feb 06 21:45:39] tobias@archlinux:~/plann (master)
$ plann --config-section=work select --uid=c9ff48a6-039c-11f1-94c1-0aa22df30662 list

308499 [Fri Feb 06 21:46:33] tobias@archlinux:~/plann (master)
$ plann --config-section=work select --uid=c9ff48a6-039c-11f1-94c1-0aa22df30662 list | cat
2026-01-07 00:00:00 : it's Saturday and I will be out of the office

Then again, the "bug" here may be in the list formatting. Indeed:

$ plann --config-section=work select --uid=c9ff48a6-039c-11f1-94c1-0aa22df30662 print-ical | cat
BEGIN:VCALENDAR
VERSION:2.0
PRODID:Zimbra-Calendar-Provider
BEGIN:VEVENT
SUMMARY:it's Saturday and I will be out of the office
DTSTART;VALUE=DATE:20260107
DTSTAMP:20260206T204536Z
UID:c9ff48a6-039c-11f1-94c1-0aa22df30662
SEQUENCE:0
CLASS:PUBLIC
LAST-MODIFIED:20260206T204536Z
STATUS:CONFIRMED
TRANSP:OPAQUE
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
END:VEVENT
END:VCALENDAR

I also notice that --version doesn't work.

[tobixen]

Regarding if the DTEND is needed or not ...

The icalendar RFC5545 does not specify very explicitly how the timestamps should be interpreted. It's sort of implicitly defined in the caldav RFC, which describes the expected search results in detail. A search for an event with a DTSTART timestamp, no DTEND and no DURATION should be equivalent with searching for an event with zero DURATION or DTEND=DTSTART. A search for an event with a DTSTART date and no DURATION/DTEND should be equivalent with searching for an event with a one day duration.

However, the RFC is not explicit on how to deal with times and timezones in the search parameters when the event is a whole-day event. The date cannot have a timezone, and the search interval should always be passed to the server in UTC-time - hence, the server has no way to know what timezone the event is held in or what timezone the client uses. This is quite relevant, a whole-day-event on the same date may actually be more than 24 hours apart depending for two persons on different sides of the international dateline. I suppose that implicitly, if a search is done up until 23:59 UTC on 1st of January or from 00:01 UTC on the 3nd of January, an event for the 2nd of January should probably not be returned - regardless of what timezone the calendar server is in. But I digress :-)

More to the point, do we have an issue here or not? :-)

[tobixen]

@davemcguire Thanks for reporting this! We've been looking into it but are unable to reproduce the issue -- as shown in the comments above, running something like:

plann add event "some event" 2026-02-26

produces the expected DTSTART;VALUE=DATE:20260226 in the ical output (an all-day event).

Could you share the exact command you ran that produced DTSTART:20260207T050000Z (a timestamped event)? Specifically:

• The exact plann add event ... command line
• Your plann version (pip show plann or check the git commit if running from source)
• Your timezone / locale settings (in case the date parsing heuristic behaves differently)

That would help us reproduce and fix the issue. Thanks!

🤖 Generated with Claude Code