Nicolas Goaziou <n.goaziou@gmail.com> writes:

> I think EXCLUDE property is a good idea, but I may be renamed to
> ICALENDAR_EXCLUDE until it is also handled by Org Agenda, if it ever
> happens. It also needs to be documented in the manual.

Handling it in the agenda can be done by an exclusion function. I
currently have this in my org-agenda-skip-function-global (along with
another function to skip items after their END_DATE):

(defun thj/skip-excluded ()
  "Skip agenda items on dates in EXCLUDE property"
  (when (and (boundp 'date) date)
    (let ((excluded-string (thj/get-property "EXCLUDE"))
          exclusions)
      (when excluded-string
        (setq exclusions (mapcar
                          (lambda (ex-date-string)
                            (equal date (org-date-to-gregorian
                                          (org-parse-time-string ex-date-string))))
                          (split-string excluded-string ",")))
        (when (memq t exclusions)
          (org-end-of-subtree t))))))

(Should probably be updated to use the org native property extraction
mechanism, but this predates my discovery of that).

> On the other hand, I'm not sure about the END_DATE property. Couldn't
> DEADLINE be used for that matter? For example, `repeater-end-date'
> could be added to `org-icalendar-use-deadline' possible values. When
> this symbol belongs to variable's value and current entry has a
> deadline, any timestamps with a repeater get deadline's value as its
> END DATE property.
>
> What do you think?

Sure, that would work. Two possible issues spring to mind:

1. Is there any use cases where someone might want a deadline (in its
current use) along with an end date? Or some other conflict?

2. Will using the DEADLINE field make it harder to add exclusion from
the agenda? (I've never really used the deadline field, so don't know
what people normally use it for).

>> +(defun org-icalendar-zero-convert-timestamp (timestamp &optional format)
>> +  "Parse and format an org-formatted timestamp, zeroing the time component."
>> +  (let ((time (org-parse-time-string timestamp))
>> +	(fmt (or format "%Y%m%dT%H%M%SZ")))
>> +    (format-time-string fmt (encode-time 0 0 0 (nth 3 time) (nth 4 time) (nth 5 time)))))
>
> Can't `org-icalendar-convert-timestamp' be used instead?

It could, conceivably. However, I couldn't find any functions that would
parse a property string into the timestamp format expected by
org-icalendar-convert-timestamp, and since I would have to modify that
function quite a bit to make it do what I needed (print a UTC timestamp
string without taking time zones into account; only the date part is
used), I thought it would be easier to just create a new function.

The above interpretation of how UTC-strings are used in the exclude
parameter may be wrong, btw. Or rather, what I've done with END_DATE
here is interpret it purely as a date stamp and ignore the time part.
Looking at the iCal RFC (I realise now), that's probably not entirely
the right interpretation. However, having the "until" value include a
time might lead to unexpected results when END_DATE is set to something
close to a repetition value.

Calling it END_TIME (or, as above DEADLINE) might get this point across
and allow for an interpretation that includes the time part. Which would
mean it would make more sense to use the org-icalendar-convert-timestamp
at least for the end date. So, how do I parse that from a string? Or
perhaps that won't be an issue if using the DEADLINE field since that is
already parsed higher up in the chain?


*ahem*, sorry if the last part became a bit scatter-brained. :)

-Toke