dtcreated/ dtstamp / last-modified
mollekopf at kolabsys.com
Fri May 31 21:39:32 CEST 2013
The issue came up if libkolab should update the last-modified timestamp of an
object when serialized. Since I've been through this before for the format,
I'll document my thoughts here and give everybody a chance to add theirs to
Part of the complexity comes from the differentiation between the conceptual
object (i.e. event) and a specific instance of the object as its serialization.
The conceptual object represents the information contained in it, while the
serialization is the text representing a version of the conceptual object.
In terms of layers, the serialization is part of a lower (transport)-layer,
and the conceptual object is part of a higher (application-)layer.
There are three types of relevant timestamps:
* $A: The creation date of the conceptual object
* $B: The last-modified date of the conceptual object
* $C: The timestamp of the serialization
Again, In terms of layers, $A and $B belong to a higher layer than $C
== KEP:17 ==
In KEP:17 I defined the last-modified  date to represent $B. There is no
representation for $C in KEP:17 as it belongs to a different layer. $C is
represented by the Date header in the MIME message  for Kolab Objects. This
is not strictly correct, but was considered a good enough approximation. After
all we don't actually want the time of serialization we rather want to know
when the file was written to storage.
== iCalendar ==
In iCal there are the following time-stamps (with a fairly confusing
* DTCREATED: "This property specifies the date and time that the calendar
information was created by the calendar user agent in the calendar
Note: This is analogous to the creation date and time for a file in the file
* DTSTAMP  : "In the case of an iCalendar object that specifies a
"METHOD" property, this property specifies the date and time that
the instance of the iCalendar object was created. In the case of
an iCalendar object that doesn’t specify a "METHOD" property, this
property specifies the date and time that the information
associated with the calendar component was last revised in the
* LAST-MODIFIED : "This property specifies the date and time that the
information associated with the calendar component was last revised in the
Note: This is analogous to the modification date and time for a file in the file
My interpretation of it is:
* If there is no METHOD:
** CREATED represents $A
** DTSTAMP and LAST-MODIFIED are equal and represent $B
* If there is a METHOD:
** CREATED represents $A
** DTSTAMP represents $C
** LAST-MODIFIED represents $B
Normally that would mean we would use LAST-MODIFIED and don't give a ****
about the DTSTAMP property which changes semantics. BUT dtstart is a REQUIRED
property for every object, while LAST-MODIFIED is optional. (IMO a shortcoming
of the RFC which might have historical reasons)
In the realm of kolab objects, we have the following considerations:
* there is NEVER a METHOD. METHOD is only used when generating scheduling
messages (which libkolab also supports, but not for kolab object). So DTSTAMP
* What we want is the semantics of $B, $C is available via the timestamp of
the MIME message, which is IMO also the layer where this information belongs.
* If I was wrong and DTSTAMP should contain $C, then we wouldn't have a field
for the last modification time, which doesn't make sense (it's clearly
something you'd want and that goes along with the CREATED property).
Thus we are forced to use DTSTAMP instead of LAST-MODIFIED with the semantics
of $B, and have to live with DTSTAMP chaning semantics when used for
See also a bug in kde  I opened for a similar issue regrading DTSTAMP and
DTCREATED.  Discusses DTSTAMP and LAST-MODIFIED and ends up using both with
the semantics of $B.
== VCard ==
In vcard there is only "rev" , which I interpreted to be the same as
$B (that's also the only useful interpretation IMO in the realm of kolab
== Implementation ==
* $A and $B can only be detected by the a user-application, as there may be an
arbitrary time-span between the time when the user creates/modifies the
conceptual object (i.e. event), and the time when the object gets finally
A good example is an invitation:
Generating the invitation shouldn't change $B, but it should change $C.
libkolab has simply no way of updating $A and $B as it sits in a lower layer
and knows nothing about when a user edited an object (those edits happen
typically against an in-memory representation and may or may not result in a
* $C is something i.e. libkolab can set because $C belongs to the
serialization which libkolab creates.
Hope that clarifies my line of though.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format