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:

Application-Level Documentation Beats Code-Level Documentation

Or how to dramatically reduce training time, speed up recovery during disasters, and make future programmers love you


Silent Failures Must Be Given a Voice

The most dangerous bugs are those you remain chronically unaware of–as all too often occurs with failing scheduled scripts


log_tokens

A simple technique to make your logs more useful when debugging