Karl Voit <devn...@karl-voit.at> wrote:

> Since no followup reaction occured: is this a but that requires much
> work? Or did my email just got lost in overfull inboxes? :-)
> 

For me, it was a "no time to work on org - stash it"...

> * Karl Voit <devn...@karl-voit.at> wrote:
> >
> > I verified the behavior below with the most current git version of
> > Org-mode.
> >
> > Whenever I call my function to export the current agenda, it
> > converts that do have a beginning and end time to events
> > that span the whole day (without begin and end times at all).
> >
> > ,----[ my LISP command to export ]
> >| (defun vk-export-agenda()
> >|   "Exports monthly Org-mode agenda to agenda.ics file"
> >|   (interactive)
> >|   (org-agenda-list nil nil 60)
> >|   (org-agenda-write "~/org/agenda.ics")
> >| )
> > `----
> >
> > I traced down the problem to this:
> >
> > * <2012-03-05 Mon 08:00-09:00> works fine
> > * <2012-03-05 Mon 8:00-9:00> works fine too
> >
> > * <2012-03-05 08:00-09:00> Wrong: ends up as full day event
> >
> > Unfortunately, I do have certain mechanisms that generate parts of
> > my Org-mode files where I skip the day of the week. Org-mode in
> > general is able to handle date stamps without day of week pretty
> > well. But whenever I export it to ics (in order to send it to
> > Google), I end up with a messed up online agenda.
> >
> > I guess that org-agenda-write is the one to blame. It would be very
> > handy to me if somebody could fix that issue.

org-agenda-write calls org-export-icalendar which calls 
org-print-icalendar-entries
which loops over all the entries and parses them, decomposing them into 
timestamps.
Each timestamp is then passed to org-parse-time-string. It's this one that 
cannot
handle non-standard formats: it uses a regexp and assumes that all the matched 
parts
are going to be in fixed places:

,----
| (defun org-parse-time-string (s &optional nodefault)
|   "Parse the standard Org-mode time string.
| This should be a lot faster than the normal `parse-time-string'.
| If time is not given, defaults to 0:00.  However, with optional NODEFAULT,
| hour and minute fields will be nil if not given."
|   (if (string-match org-ts-regexp0 s)
|       (list 0
|           (if (or (match-beginning 8) (not nodefault))
|               (string-to-number (or (match-string 8 s) "0")))
|           (if (or (match-beginning 7) (not nodefault))
|               (string-to-number (or (match-string 7 s) "0")))
|           (string-to-number (match-string 4 s))
|           (string-to-number (match-string 3 s))
|           (string-to-number (match-string 2 s))
|           nil nil nil)
|     (error "Not a standard Org-mode time string: %s" s)))
`----

You can evaluate the following in your *scratch* buffer to verify:

--8<---------------cut here---------------start------------->8---
(org-parse-time-string "<2012-03-05 Mon 08:00>")
(0 0 8 5 3 2012 nil nil nil)

(org-parse-time-string "<2012-03-05 08:00>")
(0 0 0 5 3 2012 nil nil nil)
--8<---------------cut here---------------end--------------->8---

As you can see, the time has disappeared.

As to how to fix it, there are several possibilities:

1. fix your scripts that produce time stamps to include day-of-week.
2. change the callers of org-parse-time-string to make sure that DOW is 
included.
3. change just one caller: org-print-icalendar-entries to make sure that DOW is 
included.
4. change org-parse-time-string to handle a missing DOW.

There are roughly three dozen callers, so 2. is possible but a pain.
3. is simple but ugly as sin, 4. is the best way to handle it within org.

I vote for 1. where *you* have to do all the work ;-)

Nick

Reply via email to