Wrong assumption: one hour event length when start == end

[madduck]

(This was updated on 2017-03-25 following the discussion below; original text included further down (though largely irrelevant and wrong))

While zero-duration events probably make little sense, events without a duration (i.e. an undefined duration) do.

According to the spec, such events should not have DTEND defined. Unfortunately, most clients allow DTSTART == DTEND, which the spec says is strictly unacceptable.

That said, khal/ikhal do not let you specify "no end time", and also default to one-hour duration in cases where the end time is set to be the same as the start time.

Please see the discussion following the summary by @hobarrera below: https://github.com/pimutils/khal/issues/610#issuecomment-289107374

----- Original message (ignore it, but included for completeness ----

Events with 0 duration are perfectly acceptable by my reading of the standard (RFC 5545), yet if khal encounters such an event, is says:

warning: Event start time and end time are the same. Assuming the event's
duration is one hour.

This is a false assumption. On the one hand, the standard assumes a default duration of one day, not one hour:

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.

It does seem that the standard would like you to leave off DTEND for zero-duration events:

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.

However, nowhere does it say that for this, the DTEND property MUST be absent.

Therefore, I think khal should simply honour an event as being zero-duration if DTSTART == DTEND.

[WhyNotHugo]

The spec is perfectly clear that DTEND MUST be later than DTSTART. So in truth, the scenario you're referring to is very clearly an invalid icalendar file, as per the spec.

The decision to make these one-hour events, is because that's what most calendar apps do, and therefore, what users would accept. Regarding the spec: the entries are invalid.

Description: Within the "VEVENT" calendar component, this property defines the date and time by which the event ends. The value type of this property MUST be the same as the "DTSTART" property, and its value MUST be later in time than the value of the "DTSTART" property.

https://tools.ietf.org/html/rfc5545#section-3.8.2.2

[madduck]

Heh, somehow I missed that. I am sorry. So how does one create zero-duration events with khal/ikhal? I can't leave the field empty, not can I make it the same as DTSTART…

[WhyNotHugo]

My best guess is that you can create a one-second event, not sure if others have a better recommendation. I'm not sure what a zero-duration event would represent anyway, my guess is that you actually want a one-second/one-minute thing.

[madduck]

Well, according to the spec then, this is an event without a DTEND field, and also no DURATION. I'll open another issue to handle this on input. I.e. if the end time is the same as the start time, then that's clearly what a user intended and that should be honoured, rather than the one hour default assumed.

[WhyNotHugo]

Well, according to the spec then, this is an event without a DTEND field, and also no DURATION.

No duration is not the same as zero-duration. No duration is interpreted as "no [defined] duration". It's like None != 0.

if the end time is the same as the start time

That's invalid input and should actually be rejected, both due to logic, and per the spec.

rather than the one hour default assumed

This probably won't change because it's the popular approach by most calendar apps. We don't want khal to show different than others do for invalid input (on invalid input, it's generally best to follow the de-facto standard).

[madduck]

Well, I agree about "de-facto standard", but all the popular calendar clients allow end == start to be specified, so this seems a bit of a circular argument.

I also like the None != 0 comment. You're right, zero-duration events probably make no sense. But khal/ikhal should probably make it optional to enter the end time and then just display events with undefined duration (i.e.) just a start date…

[WhyNotHugo]

Yup, DTEND is optional. Leaving that field empty should exclude the field. To sum all this up, actual changes that seem acceptable for khal (at least IMHO, this isn't anything official):

• End date should be optional.
  • If we've an empty time field: interpret the date as a DATE (rather than DATETIME).
  • If both are empty, interpret the whole thing as null
  • If only the date is empty, interpret the same day as dtstart (or the next, if the time is earlier).
  • No changes if both are complete.
• Creating a new event, or altering an event and setting DTEND == DTSTART should not be possible. It should be possible to edit exiting events and leave those fields as-are, if they're invalid.

[madduck]

Great summary. I am not sure about the last. What speaks against changing those records to be in accordance with the spec? The user could be prompted, or this could be controlled by a config option…

Can/should we repurpose this issue? Than I can edit the title and note so in the main post.

[WhyNotHugo]

What speaks against changing those records to be in accordance with the spec?

I'd like to avoid annoying the users with this sort of stuff, but it's really a personal preference, I don't feel too strongly either way.

Can/should we repurpose this issue?

It's fine by me, you can also just link to the above link in the main description if you like.

[geier]

We currently don't even support DATETIME events with no DTEND or DURATION, that is, we convert them to DATE (allday) events lasting the day the original DTSTART was one, see the documentation.

I currently don't plan on supporting zero-duration events, doing so will be a medium amount of (to me) rather uninteresting work. I will accept pull requests for it, but only from people who are a) already known to me or b) can show that they have a history of supporting open source software over long time spans.

We could however treat DTSTART == DTEND events as zero-duration events, that is convert them to allday events, as they were probably meant to be DTSTART-only events anyway.

@madduck what is your use case for DTSTART-only events (that would not be covered by allday events)?

[madduck]

One use-case is e.g. "Jane arrives on LH 1234 from ZRH" or somesuch, @geier. I use these quite a lot, actually…