Web Developers: Harmonise Your Time Zones

How it's all too easy to wind up with divergent time zones across a modern web stack

This article is part of my Confessions of an Unintentional CTO book, which is currently available to read for free online.

I’d like to share a short lesson about something that has caused me hassle over the past few years: failure to be thorough in ensuring that the time zones in all my software components match.

Time zones potentially exist in many layers of your stack: your server’s operating system; your database(s); each of your programming languages; your web application itself; the collaborating services under your control (e.g. your other servers or logging solutions); and finally, within all the third-party collaborating software services, such as analytics, mailing list managers, payment providers, and advertising services. Forgetting to sync up the time zones in every one of these different software components stymies the reliability of your data; no longer can you rely on timestamps when working across multiple layers. This makes both debugging and tracking conversions a lot more complicated than need be.

With that in mind, decide your time zone on day one and promise yourself you’ll never connect any other software components to your stack without first setting their time zones. Then finish it all off by sticking your preferred time zone in your README for all to see.


More Articles: Click here for full archive

Project-Level Attribute Normalisation

Why you should introduce a software layer close to your object relational mapper that formats attributes into clean, standardised forms


WWW vs. Naked Domain?

When starting a new website, is it better to choose domain.com or www.domain.com?


Hidden costs of accepting online payments

How hidden fees stack up so as to quadruple the cost of using online payments providers