* Bernt Hansen <be...@norang.ca> wrote: > Karl Voit <devn...@karl-voit.at> writes: > >> When an entry got processed by org-clone-subtree-with-time-shift, >> its :CREATED: property gets shifted too: >> >> #+begin_example >> * <2011-10-04 Tue> test >> SCHEDULED: <2011-10-05 Wed> >> :PROPERTIES: >> :CREATED: <2011-10-04 Tue 17:27> >> :END: >> * <2011-10-11 Tue> test >> SCHEDULED: <2011-10-12 Wed> >> :PROPERTIES: >> :CREATED: <2011-10-11 Tue 17:27> >> :END: >> #+end_example > > Where does this :CREATED: property come from? The only code I can find > is in contrib/lisp/org-expiry.el
Yes, I am indeed using this package. To be honest, I have forgotten that it is org-expiry.el which generates those :CREATED: properties. But I do find it important to know, *when* an item was created. Independently from any expiry functionality. This is not only because I am doing http://en.wikipedia.org/wiki/Lifelogging with https://github.com/novoid/Memacs by the way. > and since that isn't officially part of org-mode yet I don't know > if it makes sense to have code in the cloning function to handle > it. Oh, I thought «contrib» is also «part of Org-mode» since it is in the very same git repository. Thanks for clarification. > Maybe (if there isn't already) the clone function could use some list of > properties for special handling (ie drop this property, don't shift the > date on that property, etc) > > If it can be generically handled then whatever code you include that > adds functionality for the :CREATED: property can also update that list > so it is handled in a sensible way. I can think of different situations where such a mechanism would be handy, yes. Is Bastien Guerry (creator of org-expiry.el) reading here? So for now I am afraid I have to either deactivate org-expiry.el or remove any :CREATED: property before applying cloning. -- Karl Voit