technically, Processing has no Date object, so you're always going to be reinventing the wheel here. You can jump out of Processing and use the Java Date and Calendar objects (see  http://docs.oracle.com/javase/6/docs/api/java/util/Date.html) but I would also recommend filing an issue at  http://code.google.com/p/processing/issues/list to request access to the Date object, since it's emphatically NOT something you want to have to implement yourself (it is an incredibly complicated thing to get right, due to the various calendars that are in effect right now, and have been in effect, historically)

Thanks, but how exactly do I "jump out of Processing and use the Java Date and Calendar objects"? Can I do that in the PDE?

" I would also recommend filing an issue [...] to request access to the Date object"
I don't get it. Data and Calendar are available in Processing, like are String, ArrayList or HashMap, to name only Java classes listed in the Reference. So are all Java objects. What do you want to put in this issue report?

" how exactly do I "jump out of Processing and use the Java Date and Calendar objects"?"
You don't "jump". You just use them. At worst, you have to do an import, if not done by default by Processing.
This is not necessary here, as Date and Calendar are in java.util, always available in Processing.

Thanks phi.lho for making that more clear. Unfortunately, the timeline that I am trying to make predates 1970, so this isn't very useful to me. I guess I could just map the events manually then.

Perhaps you can use JodaTime for advanced date manipulations, it is the most reputed library in the field.

phi.lho, they're not part of the official API (you won't find them in  http://processing.org/reference for instance). Even though you can use them in the PDE, Date and Calendar are plain Java objects, like Graphics2D, Thread, and JFrame, and are not actually Processing code, they happen to just work because the code is partially rewritten to a java class and then run inside a JVM.

I understand better, although it is more a problem for the implementers of the alternative versions of Processing than for the Processing creators themselves. In the case of Processing.js, they implemented ArrayList and HashMap because they are indeed commonly used by Processing programs, and perhaps because they are in the Reference page, but Processing authors did nothing about these classes, except documenting them.
Date isn't very interesting to document, because most of its API is deprecated anyway. Calendar is quite complex to document. And to reimplement in other non-JVM languages! Even more as Calendar depends on locale, etc.

Most alternative languages has one native implementation of these classes, so it isn't a problem to use the functionality.
Perhaps ensuring portability by freezing the API (by documenting it) is good, but it isn't a major feature/priority IMHO.

No, we implemented ArrayList and Hashmap because they're in the official API (I'm a Processing.js dev, btw) =)