Bug 310469 - ical implementation mixed up dtstamp and dtcreated.
Summary: ical implementation mixed up dtstamp and dtcreated.
Status: RESOLVED FIXED
Alias: None
Product: kdepimlibs
Classification: Applications
Component: kcalcore (show other bugs)
Version: GIT (master)
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks: 310448
  Show dependency treegraph
 
Reported: 2012-11-21 22:50 UTC by Christian Mollekopf
Modified: 2013-01-03 11:53 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.9.5


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Mollekopf 2012-11-21 22:50:57 UTC
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
Comment 1 Christian Mollekopf 2012-12-24 15:22:40 UTC
Git commit c32e7b2b16eaa2d676abe8a8456dc05d0bd62793 by Christian Mollekopf.
Committed on 26/11/2012 at 20:04.
Pushed by cmollekopf into branch 'KDE/4.9'.

Don't mix up CREATED and DTSTAMP, and introduce X-KDE-IMPLEMENTATION-VERSION.

CREATED is the creation-date of the icalendar object, and not the time of serialization.
DTSTAMP is the last-modification-date without METHOD, and the time of serialization with a METHOD.

This patch fixes the following problems:
* dtstamp and created exchanged when writing any ical object
* created date is not preserved
* last-modification-date is not preserved
* vFreebusy iTip messages contain a created date (but must not)

Backwardscompatibility is ensured by only applying the fix for ical
objects which have been written using the new implementation.

For this X-KDE-IMPLEMENTATION-VERSION has been introduced to track the
implementation version which makes it possible to provide proper
backwards compatiblity.
REVIEW: 107480
FIXED-IN: 4.9.5

M  +77   -3    kcalcore/compat.cpp
M  +80   -1    kcalcore/compat.h
M  +53   -10   kcalcore/icalformat_p.cpp
M  +6    -0    kcalcore/icalformat_p.h
M  +1    -0    kcalcore/tests/CMakeLists.txt
A  +80   -0    kcalcore/tests/testcreateddatecompat.cpp     [License: LGPL (v3+)]
A  +34   -0    kcalcore/tests/testcreateddatecompat.h     [License: LGPL (v3+)]

http://commits.kde.org/kdepimlibs/c32e7b2b16eaa2d676abe8a8456dc05d0bd62793
Comment 2 Christian Mollekopf 2012-12-24 15:27:33 UTC
Git commit 7c0d110a01b6b0e38f373af95180b1f05d2f9e04 by Christian Mollekopf.
Committed on 26/11/2012 at 20:04.
Pushed by cmollekopf into branch 'KDE/4.10'.

Don't mix up CREATED and DTSTAMP, and introduce X-KDE-IMPLEMENTATION-VERSION.

CREATED is the creation-date of the icalendar object, and not the time of serialization.
DTSTAMP is the last-modification-date without METHOD, and the time of serialization with a METHOD.

This patch fixes the following problems:
* dtstamp and created exchanged when writing any ical object
* created date is not preserved
* last-modification-date is not preserved
* vFreebusy iTip messages contain a created date (but must not)

Backwardscompatibility is ensured by only applying the fix for ical
objects which have been written using the new implementation.

For this X-KDE-IMPLEMENTATION-VERSION has been introduced to track the
implementation version which makes it possible to provide proper
backwards compatiblity.
REVIEW: 107480
FIXED-IN: 4.9.5

M  +77   -3    kcalcore/compat.cpp
M  +80   -1    kcalcore/compat.h
M  +53   -10   kcalcore/icalformat_p.cpp
M  +6    -0    kcalcore/icalformat_p.h
M  +1    -0    kcalcore/tests/CMakeLists.txt
A  +80   -0    kcalcore/tests/testcreateddatecompat.cpp     [License: LGPL (v3+)]
A  +34   -0    kcalcore/tests/testcreateddatecompat.h     [License: LGPL (v3+)]

http://commits.kde.org/kdepimlibs/7c0d110a01b6b0e38f373af95180b1f05d2f9e04