Hi Eric, >>> Hang on, I am still looking into the UTC aspect. >>> >>> Right now the offset is dependent upon the execution time rather than >>> upon the date being converted. >> >> Yes, if by execution time you mean by the time zone of the computer >> running the script. This is definitely a problem and one which I gave >> up trying to solve. Mind you, it did cause me no end of problems last >> year and this year again when I moved from the UK to Australia and then >> back again... > > What I meant is that running the script during winter time applies the > winter time offset to all times, and running during summer time would > apply the summer time offset to all times. > > As far as handling the tz difference between th file and the computer, I > suggest to use a remote shell to a computer that has the same time zone > as the file. The offsets will be different, and probably the switchover > times too. Not something to handle in an awk script, I am afraid. > >> Okay. No rush from my point of view. I would love to see a solution to >> this problem! > > The attached patch provides a solution. UTC times are corrected with the > offset appropriate to that specific time. This will work for full hour > offsets as well as offsets with any number of minutes (e.g. -0145, > +0230). Still, this conversion uses the computer's time zone... > > > I added some additional configuration options that allow for easy > tailoring of the script's behaviour: > > # set to 1 or 0 to yes or not output a header block with TITLE, > # AUTHOR, EMAIL etc... > header = 1; > > # set to 1 or 0 to yes or not output the original ical preamble as > # comment > preamble = 1; > > # set to 1 to output time and summary as one line starting with > # the time (value 1) or to 0 to output the summary as first line > # and the date and time info as a second line > condense = 0; > > # set to 1 or 0 to yes or not output the original ical entry as a > # comment (mostly useful for debugging purposes) > original = 1; > > # google truncates long subjects with ... which is misleading in > # an org file: it gives the unfortunate impression that an > # expanded entry is still collapsed; value 1 will trim those > # ... and value 0 doesn't touch them > trimdots = 0; > > # change this to your name > author = "Eric S Fraga" > > # and to your email address > emailaddress = "e.fraga@ucl.ac.uk" > > > I left the default values to produce the output as you initially > intended. > > I prefer to toggle preamble, condense, original and trimdots, but that > is very subjective. > > With kind regards, > The attached patch replaces the one of my previous mail. It is to be applied to the version that is available at http://orgmode.org/worg/org-tutorials/org-google-sync.html Until now the script generated a date string for both the start and end times found in the ics file. This resulted in redundant data. If the start and end time fall belong to the same day, the script will now output one single date with a hyphen-separated time span, rather than two individual (double-hyphen-separated) dates with resp. the start date/time and the end date/time. In the same spirit, when start and end date are 1 day apart and no time info is present (birthdays, anniversaries etc.), only the start date will be output. So it would output <2013-05-11 Sat> rather than <2013-05-11 Sat 00:00>--<2013-05-12 Sun 00:00>. For dates before the epoch this would be <1913-05-11> rather than <1913-05-11 00:00>--<1913-05-12 00:00>. Have a nice weekend, Guido -- Computer programmers do it byte by byte.