[O] Ical to org, in Go lang.

[Robert Horn]

I have been working on converting ICal format files (.ics, .vcs, etc.)
into org content.  This is now ready to share (by adventurous users
only).

What it does now:

It is a command line executable, written in Go.  It takes one or more
arguments that are either local files or URLs to be fetched.  It scans
these for Ical content.  It converts the events found into text in Org
format.  At present it ignores everything else.

     The org content at the moment is of the form

     * Event Summary <start-time>
       SCHEDULED: <times>
       :PROPERTY:
       various extracts from original Ical
       :END:
     ** Description
       extracted description
     ** Location
       extracted location

It uses a modified version of the ics-golang package.  The modifications
are to deal with parsing a wider variety of Ical sources and to capture
more information that I think useful.  Different Ical creators use
different combinations of Ical components, attributes, etc.  When I'm
done I will be asking the maintainer of ics-golang to accept changes.

The output goes to stdout.


My intended uses:

     1.) Downloading and synchronizing with a Google calendar.  So far
     I've verified that it does download from google calendar URLs, and
     converts the ICal formatted content.

     2.) Convert Ical formatted attachments.  I get a lot of these in
     emails.  I'll eventually add something to emacs or mu4e. So far
     I've saved them to files and converted the files.

     3.) Convert big and small files of ICal dumps from various sources.
     For testing I've got a 90,000+ history of events (several years
     worth) that I archived from a previous job.  It shows that at the
     moment on an ordinary PC it converts at about 500 events per
     second.


Current Capabilities:
     1.) It converts my test files into org events properly.  All output is to 
stdout at present.
     2.) It fetches URLs from Google and converts them.
     3.) It reads files and converts them.
     4.) Error handling is poor and rudimentary.
     5.) It only works with explicit command line arguments.  Stdin does not 
work.  No options yet.  No help.  Stdout only.  But it does take multiple 
arguments.
     6.) Mixed URL (http:// only) and file names work.  At the moment fetching 
is done in parallel, but processing the results waits for all fetching to 
complete.  Fetching is done in parallel, but conversion waits until all the 
fetches are complete.

Definite Plans:

     1.) finish development, test files, etc. for a proper release.

     2.) Deal with duplicates somehow.  I want to have a command that I can
     automatically schedule to download and synchronize URLs from Google
     and elsewhere.  I foresee a pair of executable commands, this the
     fetch/convert and another one to merge the results with an existing
     org-mode file, eliminating duplicate events.

     3.) Settle on the most useful org layout.  For example, should
     location be covered in the body or in the headline?  I found that
     some of the locations that I get are multi-line locations.  At the
     moment location is a subordinate headline.  4.) Take suggestions.

     Where it is:

     github repository:  https://github.com/rjhorniii/ical2org-go for 
ical2org-go
     github repository:  https://github.com/rjhorniii/ics-golang for extended 
ics-golang.  This is temporary and just until the changes are stable, submitted 
to the maintainers, and accepted.


A note on time zones:

Org-mode does not use time zone tagged timestamps.  There are a variety
of good reasons for this.  As soon as you deal with significant travel
and teleconferences that originate in various parts of the world you hit
complex edge conditions.  The person involved can establish the right
thing to do fairly easily.  I've found no software calendar that handles
this properly.  For example, if I plan to be in New York on Monday and
Tuesday, Chicago on Wednesday, and Berlin on Thursday and Friday, what
timezone should be attached to which events?  I personally use the rule:
local time there and then.  So I want Monday and Tuesday to be
America/NewYork, Wednesday to be America/Chicago, and Thursday/Friday to
be Europe/Berlin.  Note that I did not use UTC offsets.  I want the
times to be then local time.  I don't want to worry about whether at
that time and location it is summer time or not.  I find org agendas are
most useful this way, even though different days and events are
different time zones.

This program converts everything assuming that the event creator local
time zone is the one that matches my rule of "then/there time".  This is
not always correct.  It is especially a problem for teleconferences
across time zones.  The creator specified time zone(s) for the event and
put in the properties drawer.  This allows a human to know what was
sent.  I then assume that between the description, the zones, and the
times, a person can decide whether and how to adjust the active
timestamps in the org file.

--
Robert Horn
address@hidden