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

Adminimisation: Tips for Building Great Admin Dashboards

How to build a robust administrative area that'll help you automate away the boring and routine tasks involved in running a web site


Project-Level Attribute Normalisation

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


Excelling at Exception Notification

Fighting inadequate exception notification– do your background queues, assistive servers, and OS report issues?