[kronolith] The DTEND value in iCalendar export and import

[Arne Nordmark]

Currently, kronolith increments time by one second when forming the 
DTEND field on iCalendar export, and decrements by one second on import. 
Thus, a one-hour event created in kronolith (with SQL backend) is 
exported with a 3601 second difference between DTSTART and DTEND.

This behaviour is not mimicked by any other calendar application or 
other source of iCalender data I have come across. For example, 
Lightning/Thunderbird, Gnome Evolution, and the Android calendar all 
export a 3600 second DTEND-DTSTART difference for a one-hour event.

The kronolith behaviour causes a number of problems when data exchanging 
data between kronolith and such applications. Events created 
back-to-back in kronolith will be shown as overlapping (by 1 second) in 
these applications. Events created by these applications will show the 
wrong ending minute (one too early) in kronolith.

The reason I am not simply reporting this as a bug is that the change 
appears to fairly recent and deliberate. For example, in ticket #12489
one finds "According to RFC 2445
the DTEND field is a non-inclusive. In other words, the actual event
ends one second BEFORE the value of DTEND. Kronolith, on the other
hand stores the event end time as an inclusive value, i.e., the event
ends exactly on the second specified. We therefore have to increment
the DTEND value by one second so that the value presented in the iCal
file is non-inclusive."

Now this does not seem to be how other implementations interpret the 
wording "non-inclusive" in RFC 5545. Rather, given and ending time 
14:00, of the three time points 13:59:59, 13:59:59.9, and 14:00:00, only 
the first two fall inside the event, that is the exact ending time point 
is excluded. Thus for example an event 13-14 and one 14-15 have no time 
point in common. This is not the same as "the actual event
ends one second BEFORE the value of DTEND".

Given the problems the current behaviour is causing and how it 
diminishes the value of the recently introduced CalDAV support (thanks 
for that!), would a bug report like this be accepted, and if not, could 
the reasoning behind the current behaviour be clarified?

Thanks
Arne Nordmark