One sure sign that people are getting into real-world web services projects is when you start to see timezone awareness creeping into web services management products. So I was quite excited when I saw that the latest release of AmberPoint's Service Level Manager has added a 'Business Agreement Calendaring' function.
Why is timezone awareness such a big deal? Because it only becomes a problem in a highly distributed, decentralized environment. So long as there's a single, central point of control, then it's easy to wriggle around timezone issues by pretending they don't exist. You can always decide that, since the data center is in Colorado, all transactions will logged using Mountain Time. Or if the company headquarters is in New York, you can decree that everything happens according to Eastern Time.
Timezones only become a problem when you start interacting on a network with other entities that are free to set their own timezone and calendaring rules. To give a simple and commonplace example, how do you decide the date of an invoice for an e-commerce sale if your company is domiciled in England, your web server is hosted in California, and the customer is located in India? If my Indian customer makes the purchase at 9.30 in the morning his time, then it's 4 am in Britain but only 8 pm the previous evening in California. If I'm using the Californian server's timestamp to decide the date, my customer's going to be invoiced a day too early. On certain days of the year, that could mean he ends up being invoiced at the wrong price and in the wrong tax period.
But the problems you might encounter with simple e-commerce transactions are paltry compared to the knots you can get tied into when delivering services across timezones. If that Californian hosting company has a big customer base in the UK, when should it schedule planned downtime, bearing in mind that midnight California is 8am in England? During what times should it staff its support desk?
Now multiply the number and complexity of those questions by tenfold or more, and you start to recognize the kinds of problems global businesses are going to start having with timezone issues as they roll out web services internationally, whether across internal business divisions or out to customers and partners. Peak hours and downtime windows will vary across multiple timezones, and if the terms of individual service level agreements are modified or upgraded, the effective dates for starting and ending each one will fall anywhere in a given 24-hour window, depending on where the parties are based. And of course all of that has to be logged with an audit trail, because the only time anyone is going to want to check out what actually happened is several weeks or months later when the client challenges the invoice.
These are the sorts of issues that don't occur to people until they actually start seriously thinking about rolling out services. So when you see this kind of functionality cropping up in products and highlighted as a marketing feature, it's a good sign that those products really are being deployed in live production projects.