Fixed in CVS.

Yes.

Jan, do we have enough info to fix and resolve this?

The clients that I've tested (Google Calendar, Mozilla Sunbird, and MS 
Outlook), all use VALUE=DATE and DTEND = DTSTART + 1 for all day 
events.  All of the public remote subscription .ics files I've been 
able to find for various holidays and other all-day events all use the 
same day numbering.  Kronolith is the only app I've found that uses 
DTEND = DSTART for all day event.  (I didn't look that hard for others.)

The RFC also reads (4.6.1):



    The "VEVENT" is also the calendar component used to specify an

    anniversary or daily reminder within a calendar. These events have a

    DATE value type for the "DTSTART" property instead of the default

    data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it

    MUST be specified as a DATE value also. The anniversary type of

    "VEVENT" can span more than one date (i.e, "DTEND" property value is

    set to a calendar date after the "DTSTART" property value).



That implies if you don't want to span more than one date, DTEND 
should be the same like DTSTART.



I guess this is simply ambigous in the specs and we should do what 
other clients do.

The patch attached to http://bugs.horde.org/ticket/?id=4794 fixes this for me.

Other calendars that handle



DTSTART;VALUE=DATE:20070212

DTEND;VALUE=DATE:20070213



as a single day from midnight to midnight rather than as two full days 
include Google Calendar, Mozilla Sunbird, and Microsoft Outlook.  I 
haven't checked any others.



Most single-day events seem to be set using VALUE=DATE with a full 
day-span between DTSTART and DTEND in public holiday calendars 
available through mozilla.org, the various calendars available through 
calendar.google.com, and the ones I checked at icalshare.com.



I've read through RFC, and this is what it says about DTEND (this is 
from 4.8.2.2):



    Description: Within the "VEVENT" calendar component, this property

    defines the date and time by which the event ends. The value MUST be

    later in time than the value of the "DTSTART" property.



If Kronolith is trying to match RFC behavior, then DTSTART = DTEND 
isn't allowed.  Which would mean that the current Kronolith behavior 
is wrong.

Ahh, okay, I'll check with the ICS author.



What about yearly events?  Will this ever be supported in Kronolith?

But that assumption is wrong. If you specify dates with the parameters 
VALUE=DATE, you mean the whole days. If you mean something different, 
you need to use datetime fields.

Will Kronolith support yearly events?
This isn't really two days if you assume that it defaults to midnight 
on each day.



If I create an event from one day at midnight to the next day at 
midnight, Kronolith shows this as a one day event in the Month view.   
Shouldn't the above assume midnight on each day, not two full day 
events?  If no time is present, midnight is a really good assumption 
IMHO.

These events are specified as 2-day events. A good example is the 
Easter Day which is specified as:

DTSTART;VALUE=DATE:20050527

in 2005, but as:

DTSTART;VALUE=DATE:20040411

DTEND;VALUE=DATE:20040412

in 2004, which is obviously two days long.

This is because Kronolith currently doesn't support yearly recurrence 
which is specified by date. And that's exactly what these events are 
in the remote calendar. Instead it assumes that the events start date 
specifies the date on which the event recurs yearly. In the case of 
Thanksgiving this start date is specified as November 25th 2004.

I am trying to get my holiday feeds via a remote calendar, but it 
appears that the dates are off.



1. Election Day and Thanksgiving are on the wrong days of the week 
according to Kronolith.

2. All full day events show up as 2 day events since midnight to 
midnight appears to be two days worth.



I have my remove calendar set to the following, as well as attached 
for convienence.

webcal://icalx.com/public/icalshare/US32Holidays.ics



I say this in 2.1.2 as well, but waited for 2.1.3 since I know some 
remote calendar bugs were fixed.



If the ICS is wrong, could you help me convince the author of such?   
If there is a better remote calendar ICS to subscribe to, I'd love a 
recommendation1 :)



Cheers, and congrats on the 2.1.3 release!!!