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:

Project-Level Attribute Normalisation

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


Minimum Viable Backups for Web Apps

A list of the various nooks and crannies needing backing up followed by a look at the most common failure modes of a backup system


Taking Data Integrity Srsly

Data Validity Spot Checks, No-Delete Policies, Database Constraints, and Care with NULLs vs. FALSEs etc.