It should have been resolved and fixed already.

Alvaro

On Monday 13 September 2010 18:50:15 ext Patrick Ohly wrote:
> Hello Alvaro!
> 
> While going through my notes I noticed that we never came to a final
> conclusion on one issue previously discussed via private email. Or
> perhaps it is resolved and I just don't know about it ;-)
> 
> The problem was related to the interpretation of the iCalendar 2.0
> CREATED and DTSTAMP properties. Here's what these fields should be used
> for (from RFC 2445):
> 
> CREATED
> 
>    Purpose: This property specifies the date and time that the calendar
>    information was created by the calendar user agent in the calendar
>    store.
> 
>         Note: This is analogous to the creation date and time for a file
>         in the file system.
> 
> LAST-MODIFIED
> 
>    Purpose: The property specifies the date and time that the
>    information associated with the calendar component was last revised
>    in the calendar store.
> 
>         Note: This is analogous to the modification date and time for a
>         file in the file system.
> 
> DTSTAMP
> 
>    Purpose: The property indicates the date/time that the instance of
>    the iCalendar object was created.
> 
>    [...]
> 
>    This property is also useful to protocols such as [IMIP] that have
>    inherent latency issues with the delivery of content. This property
>    will assist in the proper sequencing of messages containing iCalendar
>    objects.
> 
>    This property is different than the "CREATED" and "LAST-MODIFIED"
>    properties. These two properties are used to specify when the
>    particular calendar data in the calendar store was created and last
>    modified. This is different than when the iCalendar object
>    representation of the calendar service information was created or
>    last modified.
> 
> kcal has the following Incidence properties:
> 
> Incidence::created()
>   Returns the incidence creation date/time.
> 
> IncidenceBase::lastModified()
>   Returns the time the incidence was last modified.
> 
> For change tracking, SqliteStorage offers insertedIncidences() and
> modifiedIncidences(), with added and modified incidences being
> guaranteed to be listed only by insertedIncidences().
> 
> I think that the following items correspond:
>   CREATED = Incidence::created() = SqliteStorage::insertedIncidences()
>   LAST-MODIFIED = IncidenceBase::lastModified() =
>  SqliteStorage::modifiedIncidences()
> 
> Do you agree?
> 
> I believe that in the past, mkcal used DTSTAMP instead of CREATED for
> IncidenceBase::lastModified() and SqliteStorage::modifiedIncidences(),
> but I haven't checked all of our old correspondence on this, so I am not
> entirely sure right now.
> 
> I don't find anything in the Incidence that corresponds to DTSTAMP.
> IMHO it should be added as an Incidence property so that apps have a
> chance to preserve it when copying around Incidences.
> 
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to