taking the red pill

Today, I started a small project to export Outlook Data as iCalendar file. In the process, I successfully managed to create a iCalendar file that can be read by Apple’s iCal, including repeated events and such.

However, once the script correctly output events that span a year or so, I started seeing events that took place either too early or too late. After some thinking (Yo, I’m not so smart, you know) I found out that the date/time format I was using in my export was flawed.

I used the UTC notation which does not account for daylight savings, and thus events that span daylight savings and no-daylight savings (e.g. staring in June and repeating, e.g., until today) got shifted by one hour.

Tonight, I did some more research and found this very interesting article by Jon Udell. I feel I could’ve written the first phrase …

I’ll spare you the details of my excursion into MAPI (Microsoft’s mail API), using Python’s Win32 and COM extensions, plus code I cribbed from the SpamBayes plug-in for Outlook. Suffice it to say that after some fiddling, I got Outlook to disgorge my events as iCalendar VEvent records. Then the fun began. My calendar for October includes several trips to other time zones. Some of those occur before the end of Daylight Saving Time, and others after. Those of you who travel more than I do have already guessed what dilemma now arose. Outlook’s COM interface handed my Python script a UTC time object, and another field with my time zone, which it reported as GMT-05:00 Eastern Time (US and Canada). How should I represent that time in my published calendar? Here’s one choice for a 10AM appointment on October 15: DTSTART;TZID=US/Eastern:20031015T100000 But wait! That appointment is in Denver. Maybe I should publish the UTC time: DTSTART:20031015T150000Z In fact, both approaches are lame. The first looks right to me in Outlook now, will even look right to me in October (since I tend to leave my computer on Eastern Time when traveling), but is wrong from every other perspective. The second fails to account for Daylight Saving Time. So, for example, a 10 a.m. before the last Sunday in October will show up (on my local calendar) as 11 a.m.

At least I know why my script failed — I guess I will simply ignore the fact that there exist other timezones than CET.

When I was accessing some JSP page today, I suddenly got this error message:

Critical error: Unable to tell you in your localized language that another critical error has occured.

Well …

<

p>[Note: I subscribed to this particular service in english, so I wonder in what language the error message should've been presented. Java? Maybe just plain esperanto.]

There was an interesting debate at MacMerc’s about “Yazsoft cries foul against VersionTracker” which finally made me find a software that looks as the ideal candidate to end the update hassle.

It’s called “Renew” and is developed by myndlinksw.com:

We all know keeping your software up-to-date is important. Bug fixes come along, as well as security patches. Apple has provided an intuitive mechanism for keeping your system software up-to-date, but your other software is left out in the cold! Renew aims to simplify your experience and save you time by automating and integrating these tasks in the style of Apple’s Software Update.

Sounds good. And looks good as well. I downloaded and installed it. Adding Software is easy once you understand that the “Find Software” pushbutton is pretty useless and that you have to add the programs via drag’n'drop.

Renew knew a rough estimate of 60% of my software titles and promised to add the others “au fur et à mesure” to it’s database.

[Note from jr:] The first impression after running Renew’s update process for the first time: Shareware Apps seem better and more easily recognized than commercial apps. For example, Renew wanted to redownload Internet Explorer even if I had the latest version installed.

<

p>I will use it for a while. Hopefully, it becomes one of my favourite tools on my Mac.