Karl Voit <devn...@karl-voit.at> writes: > Hi! > > 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 > > Although this *might* be on purpose, I strongly argue to stop this behaviour > because of: > > * the entry is not really created in the future. It is created > either at the original :CREATED: timestamp _or_ it is created at the > timestamp when org-clone-subtree-with-time-shift is executed. > > * the user gets heavily irritated when the generated entries keep > popping up on future days. > > I suggest that at least for :CREATED: properties, the time stamp > does not get changed by org-clone-subtree-with-time-shift.
Where does this :CREATED: property come from? The only code I can find is in contrib/lisp/org-expiry.el 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. 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. Regards, Bernt
