dtcreated/ dtstamp / last-modified

Christian Mollekopf 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 [1] 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 [2] 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 [4] :  "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
calendar store."

* LAST-MODIFIED [5]: "This 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 

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 [7] I opened for a similar issue regrading DTSTAMP and 
DTCREATED. [3] Discusses DTSTAMP and LAST-MODIFIED and ends up using both with 
the semantics of $B.

== VCard ==

In vcard there is only "rev" [6], 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.


[1] https://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Last_modification_date
[2] https://wiki.kolab.org/Kolab_3.0_Storage_Format
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=303663
[4] https://tools.ietf.org/html/rfc5545#section-
[5] https://tools.ietf.org/html/rfc5545#section-
[6] https://tools.ietf.org/html/rfc6350#section-6.7.4
[7] https://bugs.kde.org/show_bug.cgi?id=310469
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20130531/392123b4/attachment.sig>

More information about the format mailing list