Of dates and computers... I stumbled into
this article in my reading this morning. It's a good, non-technical explanation of why we have leap years (this year is a leap year, by the way). This is familiar territory for me, as I've written quite a bit of code that deals with these issues. That got me to pondering just how much time I've spent over the years doing this. It's kind of crazy, really, just how hard it is!
The most recent descent into date madness that I took was about 12 years ago, when I was working for a company doing electronic stock and option trading. They had customers located all over the world, in a total of 28 different time zones. The development team was getting all twisted up in the problem of converting dates and times from one time zone to another. Our programming environment (Java) had a standard way of doing this (a “library”), but it always seemed to be missing a few of the time zones we needed. The problem was that time zones changed frequently. Mistakes in the time zone conversions could be very expensive for us, so it was worth considerable effort to get right. I ended up writing a replacement for the standard Java library that we could keep up to date ourselves. I was amazed how complex this seemingly simple problem was, especially when it dawned on me that I had to track not only the
current time zones (that was bad enough!) but also the entire history of time zones. Sheesh!
Way back in the '80s I had a consulting job that involved writing code for a different kind of date and time conversion. This time it was a university who needed a way to figure out the relative timing of events in the past, back to around 500 BC. The challenge was that people in different places used to keep entirely different calendars, and these calendars
independently changed over time. When someone in Italy wrote a date of (say) February 12, 1204, that wouldn't necessarily have been the same date in (say) Denmark; there it might be December 29, 1203. One of the big challenges to understanding those differences was that the whole concept of a country was quite fluid back then :) Even worse, in some places the researchers cared about, the calendars they used were
completely different – not the Julian calendars invented by the Romans, but totally different calendars generally controlled in quite an arbitrary and capricious manner by religious authorities.
That was a really challenging programming problem. Coming up with a model that could handle all these things wasn't too hard, but gathering the information required to fully implement that model
was. I ended up getting a grad student assigned to me as my helper, and her only job was to go get answers for me. I'd ask her a question like “When did Amsterdam switch over to the Gregorian calendar?”, and she'd go off to get the answer. In the end, the solution was more a database and less a bunch of code.
I remember one problem the researchers were wrestling with that they never did come up with a satisfactory answer for. The problem arose when interpreting the writings of someone in the past who was writing about events in an area not local to them. For example, an Englishman might write about the purchase of a ship from Amsterdam, saying something like “I bought this ship for 4,000 guineas, and it was delivered on March 17, 1366.” The problem is
which March 17, 1366 was he talking about: London's or Amsterdam's? Because they weren't the same. Most likely they'll never figure that one out :)
Anyway, I've spent a lot more programming time dealing with issues like this than I ever thought I would. The problem of dates and times keeps recurring, and I'm not sure that will ever end. For instance, there's
a debate currently underway about leap-seconds, and whatever the answer turns out to be, software will have to be written to deal with it...
