Tiger Time

When OS X Tiger was released last month, I was eager to upgrade everything with a little apple on the side. With final projects looming, though, I only made it as far as my home workstation. My G5 at the lab was just too critical to finishing my projects to risk any kind of upgrade hell. I remember thinking at the time how I would probably be dying to get Tiger on my lab machine by the time finals ended. Well, finals ended and I’m hardly dying to upgrade. In fact, most days I’m relieved to get to the lab and experience Panther which is, contrary to some reports, much snappier than Tiger. (Mail.app responds so slowly that I sometimes accidentally call it twice from Quicksilver thinking that the first one failed.) Much of the graphics hoopla that had fueled my earlier upgrade fervor has completely given way to puzzling over the random rendering glitches, especially in iTerm and Vim, which I use probably more than any other apps. iTerm’s problems usually show up as just rectangles that disappear for a split second during scrolling. The problems with Vim are a bit more drastic. And, please don’t even get me started on the problems with Illustrator CS and why I was finally forced to create a script to clean up meaningless temporary files. After a few weeks of usage, I realized that my sole reason for running Tiger had been reduced to Dashboard, which is useful but frustratingly slow and resource heavy. Plus, it has it’s own issues like widgets not properly staying put where I left them. I meticulously aligned two weather widgets at least 20 times before finally removing one of them to reclaim some resources.

With my Tiger excitement all but gone, I was beginning to wonder if I wouldn’t do better to reinstall Panther at home and wait for a few Tiger updates to lift my spirits again when I finally found something, though it may be small, to like about Tiger.

At the end of last week I was stuck on a problem I was having with some python code that I wrote. I had a whole list of UTC timestamps that I was trying to convert into the usual UNIX seconds by means of python’s rfc822 module. I unrolled a good bit of code before I finally isolated the following situation:

import rfc822
print rfc822.mktime_tz((2005,4,3,2,54,0,-1,-1,-1,0))
OverflowError: mktime argument out of range

One may immediately recognize that time as being during one of those tricky daylight savings time transitions, but the really weird thing was that the problem disappeared when I took the code home to debug, even though I was using exactly the same python build (not the ones that came with OS X). On Tiger, the python code above works flawlessly. The other bit of strangeness is that the behavior was consistent regardless of which python I used. Any and all versions of python worked on Tiger, while Nany and no python versions worked on Panther. At this point, it’s very clear to UNIX-heads that the problem is in the underlying libraries (libc to be exact, which is the base library for all applications written in C). Being now completely obsessed with the problem and irritated with having to work around such a silly problem, I decided to waste some more time and confirm that it’s actually a problem with the clib.

#include <time.h> 
#include <stdio.h> 

int main(int argc, char* argv[]) {
    char    day[100];
    time_t bsc = 0;
    struct tm btm = { 0,54,2,3,3,105,-1,-1,-1 };
    if (mktime(&btm) != -1) {
        strftime(day,sizeof(day),"%D",&btm);
        puts(day);
    }
    else {
        puts("shazamalam!");
    }
    return 0;
}

On Panther:
gcc –o timebroke timebroke.c; ./timebroke
shazamalam!

On Tiger:
gcc –o timebroke timebroke.c; ./timebroke
04/03/05

Yup, yup, looks like the underlying libraries are the problem. And, after that amusing little adventure in dorkdom, I’m still no closer to getting my python code to work on Panther. Well if nothing else, at least I’ve finally found the most compelling reason yet to upgrade to Tiger … it can tell time.

And that’s it, no more OS X posts.