[Bug 310469] New: ical implementation mixed up dtstamp and dtcreated.

Christian Mollekopf mollekopf at kolabsys.com
Wed Nov 21 22:50:57 GMT 2012


https://bugs.kde.org/show_bug.cgi?id=310469

            Bug ID: 310469
          Severity: normal
           Version: GIT (master)
          Priority: NOR
          Assignee: kdepim-bugs at kde.org
           Summary: ical implementation mixed up dtstamp and dtcreated.
    Classification: Unclassified
                OS: Linux
          Reporter: mollekopf at kolabsys.com
          Hardware: Other
            Status: NEW
         Component: kcalcore
           Product: kdepimlibs

The language is somewhat subtle, but IMO the two properties are meant to be as
follows:
* dtcreated: the creation date of the conceptual object (event, todo, ...), not
the time of serialization. It's the time the incidence with the globally unique
uid was created and MUST NOT be modified for the lifetime of the object (just
as the uid).

RFC5545 http://tools.ietf.org/html/rfc5545#section-3.8.7.1: 
    "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."

* dtstamp: The last-modified date where the content off the object has last
been altered, not the time of serialization. If the last-modified time is not
available, the serialization may fall back to write the serialization time
(just because it's a reasonable approximation).

RFC5545 http://tools.ietf.org/html/rfc5545#section-3.8.7.2: 
    "this property specifies the date and time that the information associated
with the calendar component was last revised in the calendar store."

Note that the semantics of dtstamp change if the object defines a "method"
property (iTip).

I think the wording in the rfcs could be clearer, but this way we store the
information which is actually interesting, as we shouldn't really care when the
object has last been serialized, as that is pretty arbitrary depending on
storage and transport,  and it's an information the storage medium should be
responsible for (filesystem, database, imap store,...).

Reproducible: Always

-- 
You are receiving this mail because:
You are the assignee for the bug.



More information about the Kdepim-bugs mailing list