D26662: Don't set created and last modified fields when not present in ICS data.

Damien Caliste noreply at phabricator.kde.org
Tue Jan 14 13:12:06 GMT 2020


dcaliste added a comment.


  The patch is not necessary the ideal one, but I would like to start a discussion on this matter. Currently, when calling `ICalFormat::fromString()`, all created incidences feature a `created()` and a `lastModified()` properties. They either come from the values read from the ICS data string, or they are set to the current date time by `Incidence::recreate()` from Incidence constructor.
  
  RFC 5545 is specifying that `CREATED` and `LAST-MODIFIED` fields are not mandatory. With the incidence creator setting these two unconditionally, we cannot distinguish between ICS data with or without created and last modified fields set.
  
  I wonder if we should on the contrary to the current patch, change `Incidence::Incidence()` itself, not to call `Incidence::recreate()` but just set the revision to 0 and set the scheduling id, but not set created and last modified. This would be more matching the RFC, but it is a huge change that could have unexpected consequences, since code may rely on the fact that the constructor of Incidence do set these two fields.
  
  Finally, the patch itself may indeed suffer from the same unexpected consequences.
  
  What do you think ? Should we ignore this, try to get incidence closer to the ICS data, or even don't set created and last modified field by default ?

REPOSITORY
  R172 KCalendar Core

REVISION DETAIL
  https://phabricator.kde.org/D26662

To: dcaliste, vkrause, dvratil, #kde_pim
Cc: kde-pim, fbampaloukas, dcaliste, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200114/f0ddbefc/attachment.html>


More information about the kde-pim mailing list