Wednesday, June 4, 2008

What Time Is It Anyway?

I can't believe that I feel I need to write this post. Really. But, I do, so here it goes.

Start by asking yourself a question: what time is it? A simple enough question, with a simple enough answer.

Now pretend for a moment that you had 100 people scattered around the globe on a conference call. Now ask them all, at precisely same moment, what time it is.

(Hands down, all you physics majors out there. We're ignoring relativity, since this is all make believe anyway, so everyone agrees it happens at the same instant in time.)

Now all of a sudden the answer to your question isn't quite so straightforward anymore, is it? You have to worry about dealing with multiple timezones, the international date line, and daylight savings time. The only way to deal with this is to use dates that explicitly include the timezone. Trying to deal with dates and times missing timezones is like trying to use latitudes without longitudes, or an email address without a domain. As soon as the scope expands beyond a very tiny size, it breaks down quickly.

Now, the fact that just about any standard formatted timestamp includes this information seems like it would make this pretty obvious. Email, HTTP, filesystems - they all either include a timestamp, or are universally defined as relative to a fixed timezone that you can easily base off of.

So will someone tell me why, in this day and age, the derby database chose to define timestamp columns that are missing the timezone? You wouldn't forget to make numerical types with floating point support, would you? Or strings that didn't support storing lower case? Or... well, you get the general idea.

So come on, guys. It's a big world. Databases are all about sharing information, and these days even a modest open source project can easily be sharing between half a dozen timezones across three continents. At this point, you're just making yourselves look silly.

No comments: