I get headaches just thinking about adjusting for different time zones. Actually, if time zones we’re pizzas I’d never order one. That’s how much trouble they give me. The concept behind time zones is very simple and makes perfect sense, but there are some inconsistencies that drive me nuts.

Confusing

First of all, time zones do not follow geography but are politically decided in the various countries. England has time zone GMT while France has GMT + 1. If you look at a map you’ll see that England is just north of France which would indicate that they used the same time zone, but of course they don’t. You’ll also notice that Spain is actually located west of the Greenwich median which would indicate that they used GMT just like England. Again, that is not the case. I could go on about this, but the fact is that it is really confusing.

Then there is the whole issue about daylight savings time (DST), which some countries have and some don’t. What it means is that the time zone offset between a country using DST and one that doesn’t varies from summer to winter. It just makes me even more confused.

Server time vs. local time

When you are developing websites that must take the users time zones into account then you can get into big trouble. If you only have one installation of the website, then you can control the server’s time zone and let the users pick theirs and everything is good. But if you build a web application that people can upload to their hosting provider of choice, then you cannot control the time zone anymore. You have no idea what time zone the server is running and if you do, you don’t know if it is the correct one and if it’s using DST.

So, what good does it do to let the users pick their time zone if you don’t even know how to convert it to the server’s? No good at all.

WordPress realized this and did something else which is quite brilliant. They knew that letting the users pick their time zone didn’t help to determine their local time against the server’s, so instead they made the user pick the time offset between the server and them selves. If the server time is 4:15pm and your local time is 8:15pm, then you just pick the offset +4.

It’s brilliant and at the same time sad that we in 2007 can’t figure this out in a consistent way without running into trouble. Another possibility is that I’m just slow and haven’ figured out how to do it properly. I’ll let you decide.

You’ve probably tried it a hundred times before. You start a web project and when you are finished the code is robust, simple and down right beautiful to look at. Then as times go you add more and more features on top of the original code base and it starts to become fragile, complex and ugly. This might be because customers want certain new features or you customize parts of the system for a particular customer.

The excellent architecture and coding standards might get lost over time caused by this growth and customization. The issue is that the original code base wasn’t prepared for those kinds of changes, add-ons and customizations. So how do you prepare your project from a potential future growth without spending too much time on it up front?

Expose events

A very easy way to prepare for future changes is to fire a lot of events. If your business objects have a Save() method, then it will be beneficial to add two events – BeforeSaving and Saved. That way, any future add-on can subscribe to those events and change whatever it need too. This works well for customizations and extensions. See how to create safe events in C#.

Modulize

ASP.NET 2.0 is very easy to modulize because of the many build-in providers and the open provider model. HttpModules and HttpHandlers are also a great way of modulizing an ASP.NET application. By using these features from the beginning you will find it much easier to swap entire parts of the system with new ones.

The HttpModules and handlers are a great way to extend an application with very little effort and a lot can be done pretty much plug ‘n play.

Extension model

If you expect that you or a third-party need to extend your application, then you can build an extension model which is very simple and easy in ASP.NET. If you have an extension model from the beginning of the project you’ll probably find that a lot of your build-in features will be much easier to add as an extension instead of building it directly into the core.

An extension model makes most sense if you have exposed a lot of events because then you have more options and power for the extensions. See here how you build a very simple extension model in ASP.NET.

Prepare for localization

When your application is finished and delivered, the clients ask you to create a Spanish version as well. I’ve had that request quite a few times over the years and if you didn’t prepare your website for localization it becomes a huge task. However, this is very easy to prepare for localization.

All static pieces of text – menu items, help texts, buttons, descriptions etc. – have to be put in a resource file (.resx) and it has to be done from the very beginning. It is very difficult to find all strings and put them in a resource file later.

Use multiple tiers

The rule-of-thumb that I use myself is to build my ASP.NET applications with the minimum of two tiers. The website itself and a business logic and/or data tier. Even the smallest web application will grow over time and it is absolutely essential that all the logic and data access code is kept separate from the website. So, always start with a minimum of two tiers even for your mother’s family photo site. The next thing you know is that she asks you to add a forum and diary and you know you can’t say no to your mother. With multiple tiers you also gain the benefit of swapping individual components easily. Then you can change the data tier to use a database instead of XML files without changing anything else.