Wrong Dates in iCal Birthday Calendar

To keep track of people's birthdays, I use Mac OS X's Birthday Calendar feature of Address Book/iCal. I was going through my calendar the other day, and I noticed that a birthday which I knew was sometime in January wasn't showing up. It was on the corresponding Address Book contact, though. I deleted the birthday from this contact and reentered it, which fixed that entry, but on the suspicion that more birthdays might be missing, I flipped through my calendar and found:

Address Book says Mar 23, iCal says Mar 21

The Address Book birthday field has the misfeature that it forces a year to be specified. What a rude thing for Address Book to be asking! Anyway, I'd arbitrarily picked year 1 for the year for any contacts whose birth years I didn't know. Maybe, I thought, the Gregorian reform was throwing things off. However, changing the year to 1900 didn't help matters, and in fact made them worse:

Address Book says Mar 23, iCal says June 23

Turning the birthday calendar off (which wipes out iCal's backing store for the calendar) and on didn't help matters. A web search turned up some other people having the same problem, but the only useful solution they came up with was deleting and recreating entire contacts by hand.

I wanted to see if the raw data was wrong in Address Book's database. Address Book uses Core Data in a way that makes the database difficult to work with at the SQLite command-line level, so instead I hacked /Developer/Examples/Python/PyObjC/AddressBook/Scripts/exportBook.py to emit the birthday field by adding ('Birthday', AddressBook.kABBirthdayProperty) to FIELD_NAMES and the following to encodeField: 

    elif isinstance(value, AppKit.NSCalendarDate):
        return value.descriptionWithCalendarFormat_("%Y-%m-%d")

It turns out that a number of entries had negative years, e.g. -1900-03-23 instead of 1900-03-23. I'm not sure how this happened, but here's a script (which you can download) to fix it: 

#!/usr/bin/python
"""
Fix negative birthday years in Address Book.
This work is hereby released into the Public Domain.
"""
import AddressBook
import AppKit

def personName(person):
    return "%s %s" % (
        person.valueForProperty_(AddressBook.kABFirstNameProperty),
        person.valueForProperty_(AddressBook.kABLastNameProperty)
        )

def formatDate(date):
    return date.descriptionWithCalendarFormat_("%Y-%m-%d")

def fixBirthday(birthday):
    year = int(birthday.descriptionWithCalendarFormat_("%Y"))
    if year < 0:
        return birthday.dateByAddingYears_months_days_hours_minutes_seconds_(
            -year * 2, 0, 0, 0, 0, 0)
    else:
        return None

def fixPersonBirthday(person):
    birthdayProp = AddressBook.kABBirthdayProperty

    birthday = person.valueForProperty_(birthdayProp)
    if birthday == None: return

    fixedBirthday = fixBirthday(birthday)
    if fixedBirthday != None:
        print "Fixing up %s: %s -> %s" % (
            personName(person),
            formatDate(birthday),
            formatDate(fixedBirthday)
            )        
        person.setValue_forProperty_(fixedBirthday, birthdayProp) 

book = AddressBook.ABAddressBook.sharedAddressBook()

for person in book.people():
    fixPersonBirthday(person)

book.save()

Popular posts from this blog

Sloppy Graph, Sloppy Design

Image
I was spending time trying to fine-tune a graphviz file documenting the call graph of a piece of code and describing some of the critical functions. graphviz isn't really designed for the kind of long node labels I wanted to give it, so it would do things like put nodes in places which made it have to draw arrows reaching clear across the page. Finally I realized that rather than trying to talk graphviz into reordering its nodes, I could just refactor the thing I was graphing so that the flow wasn't so darned convoluted in the first place. Before (image links to full size version): After (image links to full size version): Corollary? If it's hard to get your call flow graph to look pretty, well, the graph isn't the only thing that's ugly...
Read more

The Design of Laptop "fn" Keys

Image
On every PC laptop made in the past 5+ (10+ ?) years, many of the “F1” (F2, F3, …) keys, and sometimes some of the other keys (the arrow keys in particular) serve two purposes. When pressed normally, they act as their respective key — F1 acts as F1, etc. However, when pressed in conjunction with the “Fn” key, they perform a special function indicated by an icon on the key. Usually both the icon and the label on the Fn key will be blue (whereas the other key labels are white.) For instance: Today, one of my professors tried to hook up his laptop to the projector and was befuddled when it didn’t work. As soon as I saw him struggling, I knew that the problem was that he had to turn on the external video out. PC laptops typically have three display output modes: internal LCD only, external (VGA, or sometimes DVI these days) connector only, or both internal and external simultaneously. In order to change the mode, one typically has to ei...
Read more

Multithreaded Python, extensions, and static data

The GIL The GIL and Context Switching I use Boost.Python to write some C++ extensions for Python. I work on an I/O-bound Python program; Python has a global interpreter lock ("the GIL") which means that in a multi-threaded program, only one thread can be executing code inside the Python interpreter at once. Now, a thread can drop the GIL, and the built-in Python read and write routines do this so that while one thread is doing I/O, another thread can run. However, due to a peculiarity in how the GIL is implemented, 1 even though the actual I/O takes place during system calls that drop the GIL, the need to re-acquire the GIL after every I/O operation was killing our performance. For instance, one of the things that the application does a lot of is logging. Doing the logging synchronously -- as the code is executing and it wants to write something to its log, it needs to wait for the write to the logfile to finish before it can continue going about its business -- turned...
Read more