When I start a new project, I can be sure that there are always a number of common tasks that need to happen. These include defining document templates, the source code structure, a build file, the development environment, the continuous integration environment, common frameworks/libraries, etc. These are known quantities and they are something that I typically plan for. One aspect of a system that always catches me out, however, is time zones.

From a Java perspective, time zones are actually pretty easy to deal with. The built-in date API might not be that intuitive, but at least it's fairly easy to get to grips with. For example, if I want to be sure that I represent local time in London, I can use the following code to create a Calendar.

Calendar cal = Calendar.getInstance(
  TimeZone.getTimeZone("Europe/London"));

Provided that you remember to explicitly specify a time zone whenever you are creating or formatting dates, you should have very few problems. Of course, it's all very well actually knowing this, but time zone management is always something that I overlook until something starts misbehaving. Typical triggers include :

• Deploying the system to a server running in a different time zone (e.g. usually GMT all year round).
• Working with a physically separated team.
• Daylight saving changes during the project.

As an architect though, you have to look at things from a wider perspective than just the application tier, and this is when it can start to get tricky. For example, what happens when your application tier and database are running in different time zones? Do you ensure the application tier sends all date/times in a specific time zone (e.g. GMT) or rely on the database defaults? What if your database vendor allows time zone information to be stored alongside any date/times, do you use this feature? What if they don't? What happens if clients are connecting to your application from all over the world and sending you dates?

And it doesn't stop at the implementation of the system itself. If you're planning to deploy your system across multiple sites or countries, what do you do then? What if that deployment is active-passive; should you plan to test the DR and BCP environments?

Time zone management seems like a pretty trivial detail, but it can easily have wider implications and has played a part in every project and every architecture that I've been involved in for the last couple of years. As we build more and more systems that break down traditional geographical barriers, projects need to have somebody to look after this type of detail. For me, that's part of the architect's role.

Responses[11]

Posted by Simon Brown on 24 July 2007 10:52:00 BST #