[O] Ical to org, in Go lang.

From: Robert Horn Subject: [O] Ical to org, in Go lang. Date: Mon, 26 Feb 2018 15:35:47 -0500 User-agent: mu4e 0.9.18; emacs 25.3.1

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

reply via email to

